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ABSTRACT 


DoD has much to gain from Web 2.0 and the Ajax paradigm in open source. The 
Java language has come a long way in providing real world case studies and scalable 
solutions for the enterprise that are currently in production on sites such as eBay.com 
('http://www.ebay.com) and MLB.com ( http://www.mlb.com) . The most popular Ajax 
application in production is Google Maps (http://maps.google.com) , which serves as a 
good example of the power of the technology. Open Source technology has matured 
greatly in the past three years and is now mature enough for deployment within DoD 
systems. In the past, management within the DoD has been reluctant to consider 
Enterprise Level Open Source Technologies as a solution, fearing that they might receive 
little to no support. In fact, the Open Source Business Model is entirely based on first 
developing a broad user base then providing support as a service for their clients. 

DoD Modeling and Simulation can create dynamic and compelling content that is 
ready for the challenges of the 21 st century and completely integrated with the Global 
Information Grid (GIG) concept. This paper presents a short history of Model View 
Controller (MVC) architectures and goes over various pros and cons of each framework 
(Struts, Spring, Java Server Faces), which is critical for the deployment of a modern Java 
web application. Ajax and various frameworks are then discussed (Dojo, Google Web 
Toolkit, ZK, and Echo2). The paper then touches on Ajax3D technologies and the use of 
Rez to generate 3D models of entire cities and goes on to discuss possible extended 
functionality of the Rez concept to create a terrain system like Google Earth in X3D- 
Earth. 
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Figure 94. Diagram from thesis work done by LCDR Travis Rauch in 2006, outlining 
the ability of metadata to be used directly in the simulation to drive the 
characteristics of entities. Such characteristics might notionally be things 
like weapons or flight envelopes and ranges of various DoD platforms 

from [77].Ill 

Figure 95. The Earth tiled at two levels of detail (LOD) within an Ajax ZK tab panel 

control.116 

Figure 96. An Ajaxian Tab Panel reporting of checked-out mobile devices/books.117 

Figure 97. Diagram showing the basic idea behind LOD tiling from [68]. Note that 

as the client zooms in the amount of tiles representing the terrain start to 

increase exponentially.118 

Figure 98. A diagram of the LOD concept where the image sharpens as the distance 
to it decreases from [68]. Note how the target node changes in X3D from 
Billboard to IndexedFaceSet to Cone, as the user gets closer to the target 

node.118 

Figure 99. Step 1: Download Orthographic Imagery from Global Mapper 8 by 
clicking Download Free Maps/Imagery from TerraServer on the Global 

Mapper home screen.119 

Figure 100. Step la: Select Download Urban Area High Resolution Orthographic 

Imagery and then give Global Mapper an urban city and press Ok.120 

Figure 101. Step lb: City will load tile by tile and the orthographic imagery will be 
very high resolution (street level). At this point the user can choose 
various means of exporting the orthographic imagery from the File Export 

menu, i.e., jpeg, GeoTiff etc.120 

Figure 102. Step 2: A diagram showing downloaded elevation data. In Global 
Mapper navigate to the main menu and choose to view DEM format. The 


next step is to export the terrain data for Rez (VRML Elevation is one of 


the easier formats to export but most other formats are also supported by 

Rez).121 

Figure 103. A diagram showing Baltimore Harbor DEM data in Global Mapper 8.122 

Figure 104. Step 2b: Under the File->Export menu in the upper-left choose to export 

the elevation data in any format but VRML (.wrl file) is typically very 
easy and recommended. This is an example of DEM data from the San 

Jose area being exported to VRML.122 

Figure 105. An example of VRML elevation data from GeoMapper once successfully 

downloaded from [68].123 

Figure 106. Step 3: Run the imageSlicer to generate tiles at various LOD to match the 
specifications and needs of any specific project. Figure 106 showcases a 
few of the most important command-line switches that the imageSlicer can 

handle. Figure 106 is from [68].123 

Figure 107. Step 4: Run Rez to overlay the VRML (or additional fonnat) elevation 

data with the LOD image tree to generate X3D. Figure 107 is from [68].... 124 
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Slide showcasing the various formats that Rez supports for terrain data. 

Figure 108 is from [68].124 

Slide showcasing the various fonnats that Rez supports for X3D output. 
Note that Geospatial X3D is supported but is still in alpha testing. Figure 

109 is from [68].125 

Screenshot of Rez imageSlicer running in a terminal. In the lower right 
portion of the diagram a file view of the individually sliced tiles is shown 
as they might appear in a directory-view on a typical Windows machine. 

Figure 110 is from [68].125 

In the left section of the diagram, the GUI tool for Rez is shown which 


allows a user to set the most common Rez parameters such as levels of 
detail or tile dimensions from [68]. In the future, a GUI upgrade for Rez 
is strongly recommended. In the right section of the diagram, Rez is 
running in the terminal doing the work of overlaying orthoimagery on top 

of elevation data and then mapping the result to X3D tiles.126 

An auto generated Rez output in X3D of Oakland Flarbor from [68].126 

A diagram of Nasa World Wind’s current tiling schema from [83].128 

Delay Table based on Jakob Nielsen’s Work Outlining Client Patience 
Threshold on the Web from [83]. Note that a progress indicator is 
typically needed if the client experiences a delay between 1 and 10 

seconds.129 

Run time screenshot of Google Earth User Interface running on Mac OS X 
from [73]. Google Earth runs on most platforms including Mac OS X 

while Nasa World Wind runs solely on Microsoft Windows.130 

A Google Sketchup model of Alcatraz Island from Google Sketchup. 
(2007). Google. Retrieved July 14, 2007 from http://sketchup.google.com . 
Sketchup is an excellent 3D modeling tool for allowing “mere mortals” to 


create and publish content onto Google Earth.131 

The Nasa World Wind user interface from [83].131 

Task list for the Google Earth vs. Nasa World Wind Usability Study 
conducted at the Naval Postgraduate School Scene Authoring for 
Advanced Graphical Environments (SAVAGE) Research Laboratory in 

2007.132 

Average user-time to complete a task between Google Earth and World 

Wind.133 

Average subject-satisfaction level between geospatial systems in the 

Google Earth vs. Nasa World Wind study based on a ten-point scale.134 

Average subject-satisfaction chart showing the nearly 2:1 preference 

subjects had for Google Earth over Nasa World Wind.134 

Average time per task in Google Earth and Nasa World Wind Usability 
Study. Note that on average World Wind tasks took nearly twice as long 

to complete as their Google Earth counterparts.135 

An illustration of an Ajax-based front-end specifically designed for the 
iPhone from Amazon.com. X3D-Earth could similarly design such an 
interface for a sever-side geospatial system. Advantages of the preceding 
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Figure 136. 


are the touch screen interface and haptic controls such as the ability to 
zoom in and out by pinching inwards or outwards with finger and thumb 

on the phone’s main screen.141 

The above code shows a typical Google Maps server-side call. Figure 124 

is from [88].142 

The above code shows a typical HTTP GET Request for a Query for 

Atlanta in Google Maps. Figure 125 is from [88].143 

Incoming XML server response after an Atlanta query is issued by the 

client-side in Google Maps. Figure 126 is from [88].143 

An example of Ajaxian Maps from [89].145 

Google Maps URL Schema for Servlet Calls from [88]. Note the X and Y 

dimension and the Zoom Level Requirements.145 

Google Maps URL Schema for Servlet Calls when Search is requested 
from [88]. Note the q parameter requesting that Atlanta tiles be pulled up.. 146 
Diagram from A Technique for 3D Modeling of Buildings from [91]. 
Both researchers explored the extrapolation of 3D Buildings using 

stereoscopic techniques.147 

Automatic 3D Building Reconstruction Paper from [92]. This paper 
provides an example of leveraging computer vision algorithms to extract 

buildings from orthographic satellite data in.147 

Diagram of notional Aspect Oriented Programming architecture from 
AOP. (2007). Wikipedia. Retrieved August 29, 2007 from 

http://en.wikipedia.org/wiki/Aspect oriented programming . Note the 
direction of the arrows showing the injection of functionality at different 
joint-points into the application. This paradigm is a big shift from OO in 
that AOP lets the application be passive and receive necessary aspects at 
runtime instead of calling them directly the old way, (APIs) and 

decreasing modularity.154 

An illustration of IoC from Fowler, Martin. (2007). IoC. Retrieved 
September 5, 2007 from http://martinfowler.com/articles/iniection.hml . 

The diagrram is showing the IoC framework or assembler creating a 
runtime concrete class dependency for a MovieLister based on an XML 
descriptor. In the XML descriptor, the persistence type (CSV, SQL, etc.) 
is tied to a specific concrete class, i.e., SQLMovieFinderlmpl.java or 
CSVMovieFInderlmpl.java making the MovieLister code much more 

reusable and modular.155 

A high-level view of typical Struts architecture from [18]. Note that there 
is a clear separation of concerns between Presentation, Controller, and 

Business Logic within the architecture.159 

A high-level view of a Struts Lifecycle from [18]. Note the common 
Struts practice of populating Action forms. Struts is also kn own as an 
Action-based architecture. Also note the native Struts support for both 


conversion and validation errors through XML descriptors.159 

An example of Struts Action Code on the server-side from [18]. Note that 
Struts Actions take a standard HttpServletRequest and 
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Figure 148. 


HttpServletResponse object. The preceding underlines how the Struts 
framework effectively takes control of the standard FITML 
request/response paradigm and asserts its own control within the scope of 


the framework.160 

The main XML configuration file for Struts telling it what beans to listen 
from the client-side forms from [18]. Note that on the Java platform most 
Model View Controller Frameworks and Application Servers utilize 
XML-based descriptors for their configuration due to code-maintainability 

and the ability to hot-deploy in test-environments.160 

A diagram showing Struts connection stubs within the Presentation Layer 
from [18]. Note the Struts Tags and the call to the Application Layer, i.e., 

the User Bean, in this case.161 

Spring MVC Architecture from the Spring Framework Home Page, 
http://www.springframework.org. Accessed: August 2007. Note the 

Aspect Oriented Programming support.161 

Java code showing a typical Spring Controller from [18]. Note how much 
cleaner the implementation of the Spring Controller is than the Struts 

method of ActionForms.162 

A typical Spring Configuration File from [18]. Note the bean to class, or 
entity to business-logic mapping taking place in the code.163 


A notional Spring JSP Presentation Layer from [18]. Note that the form 
paradigm is still used however, it is less archaic in that now the Java 
entity-beans map directly to form input fields. As was seen in the 
configuration file the beans are subsequently mapped to Java classes on 


the server-side.164 

A summary of Spring Web Flow from [18].165 

A notional Spring Web Flow XML descriptor showing how the Model 
View Controller framework can establish logical links between pages to 
match the appropriate work flow for enterprise business processes. Figure 

144 is from [18].165 

A modem day (JSF) Java Server Faces architecture from [18]. Note that 
the Presentation, Application, and Business Logic layers are still 
separated. Also note, that validation and most importantly event-handling 

have been added.166 

A basic JSF entity bean from [18]. Note the JSF implementation of beans 
is clean and comprised of mainly setters as might be expected.166 


A typical JSF Configuration File from [18]. There is nothing particularly 
ground- breaking here just more beans mapped to classes and to a 
particular scope, i.e., session, request or response. It is of note that the 
new Seam framework from JBoss lets developers extend scope to 
transactions, which adds scopes such as contextual, transaction, and 

business process to the list of available scopes.167 

An example of a notional (JSP) Java Server Page containing JSF at the 
Presentation Layer from [18].168 
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Figure 149. Real world application of JSF standard web controls from [18]. Note how 
rich the client-controls are compared to traditional HTML controls. In 
JSF, each control has event listeners and properties that can be changed 

with backing beans such as a session bean or an entity bean.169 

Figure 150. A listing of new features in JSF 1.2. Glassfish, JBoss, Web Sphere and 
most other Application Servers now offer full support for JSF 1.2. Figure 

150 is from [18].169 

Figure 151. A listing of MVC architecture evaluation criteria from [18]. This is part 

one of three.170 

Figure 152. A listing of MVC architecture evaluation criteria part from [18]. This is 

part two of three.170 

Figure 153. A listing of potential MVC architecture evaluation criteria from [18]. This 

is part three of three.171 

Figure 154. A comparison of List Screen, i.e., paginated data feasibility comparison 

between MVC frameworks. Figure 154 is from [18].171 

Figure 155. A comparison of the ease of ensuring operational Book marking, by 
correctly handling dynamic state, in various MVC architectures. Figure 

155 is from [18].172 

Figure 156. A comparison of validation schemes in various MVC architectures from 

[18].172 

Figure 157. A comparison of Testability in various MVC architectures. Figure 157 is 

from [18].173 

Figure 158. A comparison of how Posts and Redirects are handled in various MVC 

architectures. Figure 158 is from [18].173 

Figure 159. A listing of the various frameworks that can plug-in to Spring due to its 

inherent flexibility. Figure 159 is from [18].174 

Figure 160. A comparison of the ability of various frameworks to support web site 
internationalization, or the ability of the site to be shown in various 

configurations for different languages. Figure 160 is from [18].174 

Figure 161. A comparison on how easily various MVC frameworks can template their 

respective presentation layers. Figure 161 is from [18].175 

Figure 162. A comparison of the amount of development tools available in various 

MVC architectures. Figure 162 is from [18].175 

Figure 163. A chart listing the various tools available in modern MVC architectures. 

Note that JSF and Struts are currently most prevalent frameworks. Figure 

163 is from [18].176 

Figure 164. Slide showing developer job-market concerns that might face influence 
their decision when choosing to learn a new Model View Controller 

framework. Figure 164 is from [18].176 

Figure 165. A chart showing Dice (Employment Web-site) Job Count Demand by 

MVC Architecture. Figure 165 is from [18].177 
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LIST OF ACRONYMS AND ABBREVIATIONS 


Ajax 

Asynchronous Java and XML 

Ajax3D 

Ajax, the DOM and the SAI working together to refresh the X3D 
Scene graph asynchronously 

AT/FP 

Anti Terrorism Force Protection 

ATI 

Array Technologies Incorporated 

CBT 

Computer Based Training 

COLLADA 

COLLAborative Design Activity 

Comet 

Design pattern allowing for server to asynchronously send data to 
the client, aka Reverse-Ajax 

COTS 

Commercial Off the Shelf Application like Oracle 

CSS 

Cascading Style Sheets 

CSV 

Comma Separated Value Flat File 

DCC 

Digital Content Creation 

DEM 

Digital Elevation Map 

DHTML 

Dynamic HTML 

DISA 

Defense Information Systems Agency 

DoD 

Department of Defense 

DoN 

Department of the Navy 

DOM 

W3C Document Object Model 

Dojo 

Ajax Framework 

DOS Attack 

Denial of Service Attack 

DHTML 

Dynamic Hypertext Markup Language 

DTD 

Document Type Definition 

DTED 

Digital Terrain Elevation Data 

DTS 

Data Transformation Service, ala SQL Server 

DWR 

Direct Web Remoting 

Echo2 

Server-Side Centric Ajaxian Framework 

EE 

Enterprise Edition, ala the Java EE 5 Enterprise Edition 

EJB 

Enterprise Java Bean 

EDS 

Electronic Data Systems 


xxiii 



ERP 

Enterprise Resource Planning Software like SAP 

FOAP 

Feel Of A Place 

GIG 

Global Information Grid 

GPL 

GNU Public License 

GWT 

Google Web Toolkit, Client Centric Ajaxian Framework 

GZIP 

GNU Zip 

HTML 

Hypertext Markup Language 

HTTP 

Hypertext Transfer Protocol 

HRMS 

Human Resource Management System 

IIS 

Internet Information Server 

IP 

Internet Protocol Address 

JAVA EE 

Java Development Suite For the Enterprise 

JDK 

Java Development Kit 

JNI 

Java Native Interface 

JSP 

Java Server Pages 

JSTL 

Java Standard Tag Libraries 

JSON 

JavaScript Object Notation 

KML 

Keyhole Markup Language 

KMZ 

Keyhole Markup Language Zip File 

LOD 

Level Of Detail 

Mashups 

Web Sites from Other Web Sites, i.e., HousingMaps.com using 
Google Maps and Craigslist data to display Real Estate data 

MOVES 

Modeling, Virtual Environment and Simulations Institute 

MVC 

Model View Controller 

Navy M&S 

Navy Modeling & Simulation 

NATOPS 

Naval Air Training and Operating Procedures Standardization 

NCW 

Network Centric Warfare 

.NET 

Microsoft’s Enterprise Level Development Suite 

NMCI 

Navy/Marine Corps Intranet 

NPC 

Naval Personnel Command 

OR 

Object Relational Mapping, i.e., Hibernate or Toplink 

OS 

Operating System 
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Representational State Transfer -RESTful Web Services 
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side, which allows for illusion of offline connectivity in Web 2.0 
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varying levels of detail 
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Remote Procedure Call 

RSS 

Real Simple Syndication 

SAI 
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SAN 

Storage Area Network 

SAVAGE 

Scenario Authoring and Visualization For Approved Graphical 
Environments 

SMAL 

SAVAGE Modeling Analysis Language 

SOP 

Standard Operating Procedure 

SOAP 

Simple Object Access Protocol 
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Structured Query Language 

TCO 

Total Cost Of Ownership 

URL 

Universal Resource Locator 

USGS 

United States Geological Survey 

VRML 

Virtual Reality Markup Language 

VV&A 

Verification Validation and Accreditation 

Web 2.0 

New Internet Paradigm Stressing Social Networks, Blogs, and 
Increased Interactivity ala Ajax 

Wiki 

Collaborative Website that can be edited by anyone 

W3C 

World Wide Web Consortium 

WGS 
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WYSIWYG 

What You See Is What You Get 
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Extensible Ajax Platform 

X3D 

Extensible 3D Graphics 
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I. 


INTRODUCTION 


A. PROBLEM STATEMENT 

The problem space that this thesis solves is determining the appropriate 
technologies for DoD Modeling and Simulation with respect to Web 2.0 and Ajax. The 
intent is to seamlessly integrate towards Web 2.0, while still remaining Global 
Infonnation Grid (GIG) compliant. This thesis also detennines the appropriate server- 
side technologies for use within the Extensible 3D-Earth (X3D-Earth) initiative at the 
Naval Postgraduate School. 

B. MOTIVATION 

The motivation behind this thesis is to provide improved geospatial systems and 
richer web site experiences for Department of Defense (DoD) employees. The 
minimization of vendor lock-in and a lower Total Cost of Ownership (TCO) for DoD IT 
Systems is also desired. 

C. OBJECTIVES 

The objectives of this thesis are to explain the technologies behind Ajax, Ajax3D, 
and Web 2.0 and how they are not only compatible with the GIG but also how they can 
help further DoD web and DoD modeling and simulation applications in the future. The 
limitations of Ajax and Web 2.0 are also discussed with specific perfonnance and 
security issues in mind. 

D. OVERVIEW 

As of 2002, the Deputy Secretary of Defense defined a new directive to do 
business over the network for the Department of Defense. 1 Coined GIG by the DoD 
Chief Information Officer (CIO), it has since become the most important point of 
strategic guidance for DoD IT management to follow to ensure that interoperability is 
maximized and that the DoD is not investing in monolithic systems that cannot “talk” to 

1 Global Information Grid. (2007, May 19). In Wikipedia, The Free Encyclopedia. 
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each other. Additional goals include minimizing the “Fog of War” on the battlefield by 
improving situational awareness through improved messaging-interoperability and more 
effective Network Centric Warfare (NCW). NCW has four basic tenets: 


• A robustly networked force improves information sharing. 

• Information sharing enhances the quality of information and shared 
situational awareness. 

• Shared situational awareness enables collaboration and self¬ 

synchronization and enhances sustainability and speed of command. 

• Each of these, in turn, dramatically increase mission effectiveness by 
military forces. 


The GIG concept was a direct result of the NCW doctrine, which was mandated by 
Office of the Secretary of Defense (OSD) in 2002 through overarching directive 8100.1 
GIG Compliance 2 . The directive states the GIG-compliant systems need to be joint and 
interoperable (Figure 1), among other things. Since that time, Extensible Markup 
Language (XML) technologies have emerged as the leading choice for DoD project 
managers to achieve GIG interoperability. 

4.1. The GIG shall support all DoD missions with information technology, for 
national security systems, joint operations, joint task force (JTF), and/or combined-task 
force commands, that offers the most effective, efficient, and assured infonnation 
handling capabilities available, consistent with national military strategy, operational 
requirements, and best-value enterprise-level business practices. 

4.2. The GIG shall be planned, resourced, acquired, and implemented in accordance 
with the DoD Directives System 5000 series for DoD issuances; DoD Directive 7045.14 
(reference (d)), and planning, programming, and budgeting system (PPBS). The 
Department of Defense's Infonnation Management Strategic Plan 

4.3. GIG assets shall be interoperable, in accordance with approved requirements 
documents, and compliant with the operational, system, and technical views of the GIG 
architecture. 

Figure 1. A partial listing of GIG policy requirements from OSD. 


2 Department ofDefense Directive 8100.1. (2002, September 19). GIG Compliance. 
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The Defense Infonnation Systems Agency (DISA) has banked on XML being a 
vital part of the GIG. 3 An easy integration between DISA, the GIG and XML are Web 
2.0 technologies. The term Web 2.0 was first coined by O’Reilly Media in 2003 4 and, 
though not formally specified, has since then grown into a household name within the 
context of the world of web development. Web 2.0 advocates the heavy usage of 
Convergence, XML and Web Services. Web 2.0 applications are often considered to be 
“social,” i.e., providing the user with a richer experience and more intuitive interfaces. 
The upcoming Web 3.0 is considered by many to be semantic in which a web application 
knows the context of what people are looking for and can adjust its behavior accordingly. 
In Web 2.0, Convergence is often synonymous with “Mashups,” or the amalgamation of 
data from several web sites to make an entirely new site entirely. Representative real- 
world examples of Convergence include Google Maps Mashups, such as 
HousingMaps.com or Markovic.com, and News Mashups, such as Digg Spy. Figure 2 
presents a “mind-map” 5 diagram of the Web 2.0 concept. Note that Ajax is a key 
component and the relative size-to-importance ratio within the mind-map. 


Web 2.0 


Figure 2. Web 2.0 Mind Map from [4]. In this new contextual definition technique the 
word to be defined is centered while the words, which define it, are clustered around the 
word and sized proportionally to their importance. 


3 Loring Werbel. (2005, August 8). XML Hardware to Power DoD's GIG Security Gateway. 

4 Web 2.0. (2007, May 30). In Wikipedia, The Free Encyclopedia. 

5 Mind map. (2007, July 24). In Wikipedia, The Free Encyclopedia. 
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Figure 3. Web 2.0 Treeview of Figure 3 from [4]. The arrows define parent-child 
relationships within technologies. For example, XMLHttpRequest is the parent 

technology behind Ajax. 


The technologies that are critical to making Ajax and Ajax3D work are the World 
Wide Web Consortium (W3C), Document Object Model (DOM), which takes HTML 
(Hypertext Markup Language) and encapsulates it into a tree-like data structure where it 
can be more efficiently accessed, and the 3D scene graph. The scene graph takes all the 
information that a 3D scene requires and implements the same DOM-like organizing 
principle on the data, storing it in a tree structure with parent and child nodes. The DoD 
can currently use Ajax 6 as an enabler in web applications, both in 2D and 3D, by 
dynamically altering the DOM and/or an X3D scene graph. Ajax allows the developer to 
write client-side code to call the server-side whenever they want, not just when a fonn is 
submitted or a back button is pressed. Furthermore, Ajax allows the web application 
developer to access myriads of Ajax web control libraries, i.e., widgets in a component- 
based, event-driven model via APIs. Such widgets can asynchronously drive a future 
X3D-Earth server-side implementation by providing rich controls to drag and drop 
geometry from pre-populated drop-down menus into the X3D space, or intelligently auto- 
suggest on city searches by mapping partially submitted user input to persistent city-data 
in the presentation layer. In a way, a widget can be considered a rich-component that 
exists on the web page, i.e., an example might be a Calendar control that is already coded 

6 Ajax (programming). (2007, August 26). In Wikipedia, The Free Encyclopedia. 
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for validation and acts just like a calendar. Such controls come already assembled in 
modem Ajax frameworks and are available for the developer to call at will, most often 
with a simple html tag instead of thousands of lines of code. 

Widgets come in all shapes and forms such as Calendars, Textboxes, Paginated 
Data Grids, et al. A component based model, such as ZK or Google Web Toolkit 
(GWT), with widgets, is currently widely recognized within the industry as being a “best 
practice” so much so that in December of 2006, Newsweek Magazine put out an article 
proclaiming 2007 to be the “Year of the Widget.” 7 Widgets are even starting to invade 
the desktop operating system as can be seen in Figure 4. Ever since Mac OS 10.4 
“Tiger” was released three years ago, Apple customers have enjoyed Dashboard, which is 
an Application on the Dock, which lets users customize their own workspace with helpful 
utilities called widgets. The widgets typically cover domains such as weather, stock 
reports, and news. Since it’s inception, Dashboard has become one of Apple’s biggest 
successes with Mac OS X. Furthermore, Dashboard will continue to play a huge role in 
Apple’s next release of OS X 10.5, deemed “Leopard.” In Leopard, a new technology 
called “Web Clip” will allow the client to make a widget out of nearly anything that is 
dynamic on the web. Ajax is clearly the leading technology behind the use of widgets on 
the web and looks to be so for a long time to come. X3D is currently the leading open 
source standard for 3D Graphics on the Web. DoD Modeling and Simulation can also 
benefit from this “widgetization” by applying it conceptually in 2D, and in 3D, in what 
has been coined Ajax3D which is a technique that, albeit is in its infancy, might allow 
event-driven dynamic access to an X3D scene graph without any scene refresh on the 
client-side X3D browser. 


7 Brian Braiker. (2006, December 30). The Year of the Widget? 
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Figure 4. The Dashboard application on Mac OS X “Tiger” showing one user’s 
particular widget setup. Note the weather widget near the bottom of the screen and the 
Radio Paradise Web Site widget, which is using Real Simple Syndication (RSS) 8 to 
obtain streaming data. RSS is an XML-based data format typically used to stream blog 

information, news, and podcasts. 



Figure 5. An example of an Ajax Component or “widget” from the Dojo Toolkit 
library 9 . This widget is called a fisheye control and is embeddable in any web 
application. If the widget looks familiar, it is the same type of user interface that Apple 
uses for their Dock in OS X “Tiger.” Previously, components such as the fisheye control 
were not practical to implement on the Internet. 


8 RSS. (2007, August 23). In Wikipedia, The Free Encyclopedia. 

9 Dojo Toolkit Fisheye Demo. (2007, September 14). Dojo Toolkit Homepage. 
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Such features can be critical for integration into an open source server-side 3D 
geospatial system implementation, something that currently does not exist but that the 
DoD can use. Imagine a soldier in the field being able to pull up 3D terrain data with 
overlays in the field on a GPS-Enabled mobile device. Such a device might currently be 
akin to a Blackberry or iPhone. X3D models automatically generated by Rez, an open 
source orthographic image tiling tool, might feed a server-side (read Web-Based) open 
source geospatial system similar to Google Earth but free of licensing costs for the DoD. 
Google Earth started after Google acquired a small start-up company named Keyhole. 
Keyhole was an innovator in the field of Web-based Geospatial Technologies and had 
created an XML based fonnat for overlaying information on top of 3D terrain geometry. 
The format was named Keyhole Markup Language (KML). Similarly, for the X3D Earth 
initiative, information layers might be overlaid on top of X3D scenes by combined 
support for KML. Layers allow for users to see landmark data, demographics, zip codes, 
and an endless possibility of data relating to the overhead terrain they are currently 
viewing. Currently the use of Ajax is most well known in the 2D Google Maps 
Application that has recently garnered worldwide attention due to its ability to allow 
users to navigate even at the street level, a technology Google calls Street View. Due to 
its Ajax nature, i.e., loading only parts of the page that need updates, Google Maps 
performs well on today’s smart phones like the iPhone. 

If 3D is ever to be realized on the server-side, Ajax can be an important addition 
to its success considering that in such a system the demands on the network might 
increase by orders of magnitude. By utilizing a fleet of vans and driving through 
metropolitan areas with their new Street View technology, Google has pioneered a new 
type of application and is pushing the boundaries of Ajax and Web 2.0. It is time for 
DoD Modeling and Simulation and DoD IT in general, to start leveraging that same 
power. As you read this, industry is already shifting towards a web-based applications 
approach 10 , which is only made possible by Ajax being the enabling technology. In fact, 
Microsoft has begun an effort to attempt to port its entire Office Suite to the Web in what 
is known as its “Live Strategy.” 11 

10 Michael Galore. Microsoft Sees a Mixture of Desktop and Delivered in its Future. 

11 Microsoft Premiers First Live Strategy. (2005, November 1). Microsoft. 
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Figure 6. A Rez auto-generated X3D view of the San Jose metro-area created using 

open source tools Rez and imageSlicer. 


The new server-side Ajax request paradigm of keeping a record of the client’s 
current DOM state on the server and tracking any client changes to their own DOM so 
that only the actual changes traverse the network, and not the entire DOM tree is a key 
enabler in the effort to make server-side 3D a reality. Ajax also has two offline variants 
that give the user the ability to work offline as if they were online, i.e., Server Push/Pull 
(Dojo framework) or Reverse Ajax (Dojo/Comet). Server Push/Pull is basically the idea 
of polling the server or sending periodic updates or heartbeats to the client in low 
bandwidth domains, which in turn consumes less bandwidth than a nonnal connection. 
Reverse Ajax works by installing a small piece of client-software on the user base 
machine, which acts as a local web server. From that point, the technology runs the web 
application client-side by simply using the general local host or (loopback) interface at 
127.0.0.1 creating the illusion of connectivity while saving state data to the client as well. 
Once the client is again connected to the Internet, Reverse Ajax pushes all the saved state 
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back to the various web sites in question. From a DoD perspective, the preceding can be 
a significant change in the way business is done, as being actively connected will 
occasionally not be necessary to do work. By using Server Push/Pull or Reverse Ajax, 
the DoD might be able to provide rich client-side web applications to low bandwidth 
customers such as forward deployed units, be it the soldier in the field on a mobile device 
or a sub surface platform. 



Figure 7. New Google Maps Street View from [12], showing panoramic view of Times 
Square. Google Maps 12 is the most famous real-world application of Ajax technologies. 


For the GIG, open source technologies are the future. History tends to repeat 
itself, if one never learns from it, and the DoD does not have the best historical record 
acquiring IT Systems that are of moderate cost and provide adequate interoperability. 
Over the past few years, the DoD, and particularly the Navy have made critical mistakes 
in their decision to implement an enterprise-level proprietary solution in Navy and 
Marine Corps Intranet (NMCI), so much so that NMCI hate-blogs have been established 
by the end-users who work in the environment every day. By contracting out critical IT 
infrastructure and administrative privileges to Electronic Data Systems (EDS), many 
commands find it unnecessarily harder to do their daily work. No matter how much the 
DoD wishes to “make it so” declaring a set of Dell hardware and Microsoft enterprise 
applications be the only thing officially on the network is not an architecture. Further 

12 Google Maps StreetView, Google Maps. 
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disturbing is the NMCI commitment to Microsoft being the panacea for enterprise 
solutions within DoD. The more sensible approach to the preceding dilemma is not to 
entirely dispose of the idea of out-sourcing IT requirements and using proprietary 
software but rather to inject outsourcing into the enterprise where it makes sense and to 
utilize open source where it makes sense. Recently, a new directive from the Department 
of the Navy (DoN) CIO has actually made some progress in this area 13 . The word sense 
is used here in tenns of general financial cost, security, and maintainability. The current 
DoD approach is to essentially “paint the walls” with Microsoft from top to bottom and 
not worry about saving huge amounts of capital by leveraging open source. DoD must 
also recognize that Microsoft is hardly an innovator within the industry and more often 
than not their products are not “best of breed,” but rather mediocre attempts to copy the 
current industry “best of breed.” One needs to look no further than how Windows Vista 
looks strikingly similar to Mac OS X, which was released years earlier. 

In 2002, at Navy Personnel Command (NPC), in Millington TN, the transition to 
NMCI can only be described as a disappointment. Password resets took hours on 
average, the security scheme was extremely draconian (no client-side privileges at all, 
even if you had to install anything as a developer to work). Furthermore, NMCI 
scheduled network software pushes to client-machines during working hours, so if the 
end-user had to suddenly access their PowerPoint for a presentation they were denied 
machine-access until NMCI was finished with the remote install. During the initial 
deployment at NPC, NMCI also forgot a few fundamentals on the hardware-side as they 
issued laptops to enlisted detailers without any way to secure them in their docking 
stations then later found them missing after being stolen during the night. Any time a 
deployment within the enterprise is referred to as a verb in the negative context, the 
deployment is probably not going as well as originally planned. 

Another example of proprietary solutions turning into disasters was the Sea 
Warrior initiative that was well on its way at Navy Personnel Command in August of 
2002. Sea Warrior encompassed a new and ambitious human capital approach to 
empowering and educating the sailor to, in effect, have more power over the assignments 

13 Joe Barr. (2006, July 7). Navy Open Technology Development Roadmap. 
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process. In certain cases of special assignments with undesirable geographic locales the 
sailor proceeded to actually “detail themselves” to a large degree (read bid for jobs ala 
eBay). In this bidding architecture, the bonus for accepting the billet turned into an 
auction with the sailor bidding the lowest getting the desired billet. The other primary 
tenet of Sea Warrior was to automate the slate of jobs that an individual sailor might see, 
as available, thereby letting a sailor “detail themselves” in theory at least. The preceding 
was accomplished by matching a sailor’s experience and education to a five-vector model 
and having the application accordingly pull up a list of the most appropriate billets. 

The only problem with Sea Warrior at NPC was that the project’s leadership was 
too intent on making the Navy’s requirements fit into the Commercial Off the Shelf 
(COTS) product and not the other way around. The Sea Warrior Project at NPC suffered 
from a large requirements impedance mismatch that was never addressed. As is always 
the case, it is wise to surround oneself with people who will tell you “No.” The 
preceding was the exception and not the rule with the leadership heading this new 
initiative. Under the Sea Warrior Project, PeopleSoft an Enterprise Resource Planning 
(ERP) company ala SAP was chosen as the platform on which this new concept or 
Human Resource Management System (HRMS) might be drawn out. However, three 
years, later in 2005, Larry Ellison gave PeopleSoft 10.3 billion reasons to quit and 
acquired the company under Oracle. The result of the preceding was effectively the 
death of the Sea Warrior Project at NPC, owing to the fact that 125 million dollars had 
already been spent coding Sea Warrior in the HRMS module using PeopleSoft’s 
proprietary code. In retrospect, the project was doomed to failure either way since it had 
some of the worst requirements creep that one might imagine. Disruptive technologies 
are a nice driver for a new project, but at some point, requirements need to be frozen for 
the good of the life of the project. If the preceding does not happen a project typically 
dies and leaves only a heap of PowerPoint behind as remains. The same classic situation 
that one reads in software engineering texts from the 80’s happened at NPC and three 
years later they were no closer to having anything tangible than when they started. 

After the acquisition by Oracle, all of NPC’s PeopleSoft code had become much 
more useless, unless of course NPC had even more money to commit to Oracle HRMS 

conversion tools or simply buy the Oracle HRMS altogether and recode the application. 
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Contrary to the belief of many at NPC, the takeover of PeopleSoft was hostile. While 
Oracle currently supports legacy PeopleSoft applications, through the usage of expensive 
conversion tools make no mistake that, in the future, the preceding will only get more 
costly as Oracle views PeopleSoft as a legacy system. Due to the rising costs of 
maintenance, the customer will eventually be forced to either “jump ship” or migrate to 
another vendor. A third choice might be to simply cave-in to the Oracle lock-in 
nightmare. Such is the problem with COTS and therein lies the motivation to maximize 
open source throughout the DoD enterprise. 

The point of the previous story of a real world experience is not to belabor the fact 
that Oracle or Microsoft are inferior to open source or that outsourcing is unequivocally 
bad. Microsoft is actually a very good alternative to open source for a number of 
enterprise situations since nearly all of their products will be tightly integrated with the 
Operating System (OS) on the server-side if you are running Windows Server 2003 or 
any enterprise-level OS that they sell. Examples of the preceding might be the Data 
Transformation Service (DTS) in Microsoft Structured Query Language (SQL) Server 
that lets the Database Administrator (DBA) schedule complex tasks in the database using 
a GUI drag and drop What You See is What You Get Interface (WYSIWYG). The DTS 
is automatically integrated into the OS Scheduler so that no batch files handling complex 
data transactions at night need to be maintained. Ligure 8 is a screenshot of a typical 
DTS Workflow. 
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Figure 8. DTS Interface in Microsoft SQL Server 2000 showing various stages of 
dataflow. DTS is useful in SQL Server because it tightly li nk s data processes with the 
operating system scheduler since both are Microsoft products. 


The point of this case study is to illustrate that proprietary solutions are not 
always the best way to go. At the enterprise level, open source technologies are currently 
at the point where they are mature enough to be deployed in mission-critical 
environments such as the DoD’s GIG. Private industry has already adopted open source 
with open arms, owing to several reasons but most importantly the significantly lower 
Total Cost of Ownership (TCO) during the lifecycle of the application due to 
significantly lower licensing costs and a reduction of vendor lock-in. Examples of 
successful case studies include the transition from .NET to the Java Enterprise Edition 
(EE) platform by eBay.com in 2003, and the transition ofMLB.com to Java EE. 


E. THESIS ORGANIZATION 

This work is oriented towards applied technology. Because the problem space is 
so wide it is intended to give a cross section of the issues that a software development 
manager can potentially face in the DoD when a slick contractor comes in and proposes 
that their new Ajax Framework is the “best,” or that Ajax is the solution to all of the 
enterprises woes. Furthermore, on the 3D side, it is meant to show the potential Ajax has 
in being a founding technology for a truly server-side 3D geospatial system. It is the 
author’s intent that someday a proof-of concept geospatial system be written for the DoD 

13 
























to utilize royalty-free content and open standards like the X3D specification. This work 
serves as a starting point, with which both DoD IT and DoD Modeling and Simulation 
can start to explore Ajax and incorporate Ajax methodologies into their respective 2D 
and 3D applications where they give the sailor or soldier great training value. 

Chapter III focuses on giving the reader a brief introduction to Ajax technologies 
and its Dynamic HTML (DHTML) roots. An outline of the five technologies that 
encompass Ajax is presented along with high-level views of typical Ajax architectures. 

A juxtaposition of classic and Ajax web application models is then presented to the 
reader. Finally, a discussion of the pros and cons of current popular Ajax frameworks is 
given. 

Chapter IV focuses on giving the reader a brief introduction to Ajax performance 
issues. An outline of the various fonns of JavaScript compression is introduced along 
with methodologies of minimizing JavaScript white space. The avoidance of invoking 
expensive JavaScript method calls is also discussed along with a graph showing the 
impact of several of the most egregious offenders. Finally, a discussion of how different 
browsers are good at certain data-tasks, but not so much with other tasks is introduced. 

By reading the chapter, the reader can gain an appreciation for the importance of 
knowing the end user as to optimize their online experience by targeting development for 
the browser that is used by the largest number of clients. 

Chapter V describes Ajax security and JavaScript security in general. The chapter 
first introduces the Sandbox or “Server of Origin” concept to the reader, which is 
essential to understanding how modem day server-side scripting attacks work. From that 
point, Cross Site Scripting (XSS) is discussed along with modern day examples. Cross 
Site Request Forgery (XSRF) is then introduced along with the real life example of the 
Sarny Worm that hit MySpace.com in 2005. Finally, a discussion of the most popular 
methods of preventing Scripting Attacks is discussed, and applied towards the real world 
example of how Google responded to a Gmail vulnerability in 2006. 

Chapter VI focuses on good design paradigms or patterns for Ajaxian Web 
Development. An outline of the popular Representational State Transfer (REST) 
architecture for Web Services is discussed which can currently be seen in practice on 
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such sites as eBay and Amazon. The focus is then shifted to the other major Web 
Services Paradigm, Remote Procedure Call (RPC) and its variants such as XML-RPC and 
Ajax Stub of which Flickr is the most notable spin-off. From that point, the HTML 
Message Pattern and XML Message Pattern are discussed which have been made most 
popular by Google Maps, and their set of APIs. 

Chapter VII introduces Ajax3D, which introduces the reader to the abstraction of 
the Ajax concept to three dimensions. A brief description and diagram of the X3D Scene 
Access Interface (SAI) is first presented to the reader as a conceptual tool with which to 
understand how Ajax works in the 3D realm. From that point, a discussion of how to 
appropriately leverage the current XML standard for describing terrain, Keyhole Markup 
Language (KML) into the X3D-Earth project is undertaken. Following the preceding two 
exemplars are presented to the reader. The first being a basic “Hello World” example in 
Ajax3D and the second being a more complex Dynamic Scene Creation Model. 

Chapter VIII focuses on the current X3D-Earth initiative at the Naval 
Postgraduate School and outlines how Ajax methods can be applied to further solve this 
problem. The chapter begins with a quick overview of the X3D-Earth initiative at the 
Naval Postgraduate School along with a short overview of the current Geospatial node 
specification. The chapter discusses current KML specification and goes on to describe 
how it is tightly integrated into Google Maps. From that point, the new KMZ or zipped 
Collaborative Design Activity (Collada) format is introduced as a fast way to build 3D 
building overlays as seen in Google Earth. The focus is then shifted to how Collada can 
complement the X3D-Earth initiative by allowing for easy imports of 3D buildings. 
Chapter VIII also introduces the reader to Google’s 3D Warehouse Repository and 
compares and contrasts Google’s 3D archive with the Savage Studio archive managed by 
the Modeling and Virtual Environments For Simulations (MOVES) Institute at NPS. 
Specific topics discussed include the importance of meta-data within 3D repositories and 
licensing issues that come with the utilization of 3D Warehouse models. Finally, a 
methodology for importing X3D Geometry from the KMZ format into Blender is shown. 

Chapter IX discusses Rez, and open source enabler for X3D-Earth. Rez is a tool 
for overlaying tiled high-resolution orthoimagery on to X3D terrain data. 
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Chapter X focuses on usability within geospatial systems. In particular, it 
describes a usability study that was done at the Naval Postgraduate School between 
Google Earth and Nasa World Wind in 2007. The focus of the chapter begins with a 
description of the methodology along with a copy of the task list presented to each 
subject. The full results in terms of system preference and time to complete each task are 
then presented for the reader in both tabular and graphical forms to evaluate at their own 
discretion. Finally, a discussion of the results and a series of recommendations is 
presented based on the recorded video, task completion times, and the pre and post¬ 
assessment questionnaires administered during the study. 
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II. BACKGROUND AND RELATED WORK 


A. INTRODUCTION 

This chapter seeks to give the reader a background into previous research efforts 
on the server-side along with a brief introduction to Ajax technology, JavaScript and the 
pros and cons of various Model View Controller (MVC) frameworks. A program manger 
might most likely have to ultimately decide if embarking on a new Java web application 
for the DoD which of the best MVC frameworks meets the needs of their situation in the 
best manner. The MVC framework is the background and foundation needed to 
successfully leverage any web application in Java by separating the data layer (data and 
code) from the presentation layer (html). The preceding effectively stops programmers 
from creating convoluted code bases that are impossible to maintain or find experts on 
since the code might not have standardized structures (design patterns) behind it. Once 
an appropriate MVC framework is chosen and implemented the IT Manager can then 
fully leverage the power of Web 2.0 and easily incorporate Ajax, Ajax3D, Web Services 
or any other component on top of the framework with a much lower chance of project 
failure. While the choice of application server platform is also very important, most web 
applications can be successfully ported between application servers. Therefore, the initial 
choice is not nearly as critical as with MVC as it does not code the project into a comer. 
The most popular Java web application servers today include Apache Tomcat, Web 
Sphere, JBoss, and most recently the Sun Glassfish Project. 

B. BACKGROUND 

Ajax is essentially a new type of HTTP (Hypertext Transfer Protocol) request 
called XMLHttpRequest that allows the server to keep track of the W3C Standard 
Document Object Model (DOM) for the client. Whenever, the client updates a page, or, 
in some frameworks, a section (zone) of the page, the XMLHttpRequest object sends an 
asynchronous request back to the server in order to rectify the differences between the 
client DOM and the server DOM. Once the differences are rectified, the 
XMLHttpRequest object allows the DOM on the client side to dynamically update rather 
than be entirely refreshed, and the client observes the preceding as an instantaneous 
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change rather than a time-consuming page refresh. JavaScript is an essential keystone in 
the Ajax framework in that it is what is required to do the DOM manipulations on the 
client side. Figure 9 shows a simple diagram describing a typical Ajax architecture 14 on 
the client and server-side. 



an intennediary between the JavaScript calls and actually returning server-side data. In 
most modem frameworks, the Ajax Engine abstracts-away JavaScript from the developer 

and lets them stay completely in Java. 

Ajax does incur a network bandwidth overhead as, at times, complex JavaScript 
needs to be sent over from server to client. Comet 15 or Reverse Ajax is also a major 
consideration when dealing with any requirements that may need asynchronous behaviors 
on either the client or server side. Comet technology allows the server-side to push data 
asynchronously to the client-side. Comet technology is currently more cutting-edge than 
Ajax but the two domains complement each other well. Comet seeks to eliminate 
unnecessary requests by the client for new information by having the server push the data 
only when the user needs it in a “Just In Time” fashion. 

In September 2003, Capt. James D. Neushul, USMC, wrote a landmark thesis. In 
his thesis, he basically created a running web server that downloaded DTED (Digital 

14 Basic Ajax Architecture, TopCoder.com. 

15 Comet (programming). (2007, August 26). In Wikipedia, The Free Encyclopedia. 
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Terrain Elevation) data for any requested region and build X3D from it 16 . Capt. Neushul 
used a DTED data to X3D via XSLT (Extensible Stylesheet Transformations) approach 
to generate the X3D terrain dynamically. At the time, this was a remarkable first for 
X3D and a good step towards what today is the X3D-Earth Initiative. While the thesis 
was outstanding, the methodology still had no way to overlay the terrain data with 
detailed imagery in any efficient manner other than manual addition. Figure 10 is a 
screenshot image taken of Capt. Neushul’s thesis work in action, note the tiling and the 
geospatial annotations displayed: 
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Figure 10. An automated view of DTED data in X3D using James Neushul’s server-side 

DTED-to-X3D solution from [161. 


16 James Neushul, Interoperability, Data Control, and Battle space Visualization Using XML, XSLT, 
and X3D. Master’s Thesis, Naval Postgraduate School, Monterey, California, September 2003. 
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Figure 11. An architecture of Capt. Neushul’s server-side XML solution for DTED data 

to X3D from [16]. 


JavaScript is the engine behind the ability to use Ajax as it is essentially what 
allows the client side browsers to become (rich, fat, etc...) Current Ajax frameworks 
have abstracted the JavaScript out of the hands of the programmer and automate client- 
side scripting with translation engines (ZK, GWT, Echo2, Dojo). However, if it is 
absolutely necessary modern Ajax frameworks are still flexible enough to allow the 
programmer to dive in and actually have to code in JavaScript. 
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Figure 12. An example of a Model View Controller architecture from [17]. Model View 
Controller is a framework used to make web applications more modular by taking code, 
which historically resided in the Presentation Layer and porting it to the Application 
Layer. In this paradigm, the Model represents the data, and the presentation layer is the 
view. The controller handles the business logic. 


C. MODEL VIEW CONTROLLER (MVC) BASED ARCHITECTURE 

The MVC architecture 17 is a way of ensuring that the various employee(s) who 
develop or maintain a new or existing web app do not trip over themselves and write code 
that is intertwined and spaghetti-like because they ignored minimizing business logic in 
their web pages. One can think of the MVC concept as an “orange” where the goal is to 
serve various slices of an orange to hungry customers. The mechanism for providing the 
slices to the customers be it a knife or ones fingers to peel the slices can be the Controller 
in this case. The outer shell of the “orange” that people see might be the View. Finally, 

17 MVC Architecture Summary. (2007, August 17). PHP.net. 
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the actual “orange meat” itself is the Model. In the case of an orange what users really 
care about is how easy it is to get to the Model or the data. For a web site, that goal is 
data or information which typically rests on a backend database of some type be it 
Oracle, SQL Server, PostgreSQL or MySQL. So to repeat, the Model for a website is the 
data that drives it. The View just like the “orange peel” is basically what the client or 
user sees to get them to where they need to be in order to access the model. Just like the 
“peel” the View sits on top of the Model but is a distinct and very different part of the 
“orange.” Furthennore, to satisfy the MVC paradigm, page requests must go through the 
Controller before they are routed to the client. So, in effect, if one were to be the “Sheer” 
they might be the only Sheer in town with the only “orange” (data) in town. The 
preceding is somewhat crude technically but conveys the idea well for beginners. In the 
following paragraph the major MVC models written for the Java platform will be 
discussed with the pros and cons of each architecture in mind. 

D. COMPARISON OF LEADING MVC FRAMEWORKS 

For the DoD project manager who is in charge of a web application or a 
simulation, the choice of MVC architecture can either propel a project towards success or 
doom it to failure. The preceding statement is a bit of a dramatization but if the wrong 
MVC architecture is chosen for a specific set of requirements, management might 
ultimately need to pull the plug on development down the road and call for a complete 
rewrite. Today’s mainstream MVC architectures on the Java Platform are: Struts, Spring, 
(JSF) Java Server Faces, and JBoss Seam. Struts has available since January of 2001, 
while Spring and JSF are younger by three years. JBoss Seam has been available since 
2005. Spring is currently the MVC of choice for most project managers who are starting 
from scratch due to its breadth and support of Aspect Oriented Programming (AOP) and 
Inversion of Control (IoC) architecture, which allows for a greater degree of decoupling 
of dependencies between business logic and the application server. The preceding is an 
industry trend, which is most likely not going to go away, JBoss Seam utilizes AOP and 
IoC as well. However, Struts still does own a majority of the market share at 
approximately 60%. Furthermore, as a manager it will undoubtedly be easier to find 
personnel familiar with Struts. 
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MVC Web Framework Comparison 18 

• Struts used since Jan 2001 

• Spring used since Jan 2004 

• JSF used since Jul 2004 

• JBoss Seam used since 2005 

Struts Pros: 

• Lots of Struts projects out there 

• Good tag libraries 

Struts Cons: 

• Action Forms are counter-intuitive for most 

• Struts test case only does integration, project “rumored” dead 

• Struts quickly becoming obsolete 

Spring Pros: 

• Lifecycle for overriding binding, validation, integrates with many 
view options easier such as Java Server Pages (JSP) and Java Standard 
Tag Libraries (JSTL) 

• Tiles, Excel, PDF, Inversion of Control makes applications easier to unit- 
test 

• Supports using Business Logic (POJOs) Plain Old Java Objects while still 
support (EJB) Enterprise Java Beans 3.0. 


Spring Cons: 

• Configuration intensive (Lots of XML) 

• Requires lots of code in the Presentation layer (JSP) 

• Too flexible (lots of XML configuration files) no concrete controller 

JSF Pros: 

• Sun Java EE 5 standard, plenty of demand and jobs 

• Fast and easy to develop with 

• Rich navigation framework 

JSF Cons: 

• Tag soup for JSPs 

• Does not play well with REST or security 

• No single source for implementation 

• More of a Presentation layer framework and less of a strong MVC 
framework 


18 Matt Raible. (2006). Comparing Web Frameworks. 
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JBoss Seam Pros: 

• Supported by Gavin King, who created the well known and industry 
respected Hibernate, (O/R) Object Relational Mapping tool, which binds 
Java objects to SQL statements on the backend. 

• Like Spring, supports using POJOs for business objects while also being 
fully compatible with EJB 3.0. 

• Supports eliminating modular cross cutting concerns with an architecture 
based on Aspect Oriented Programming (AOP). 

• Supports the ability to code in AOP using AspectJ 
JBoss Seam Cons: 

• Not directly supported by Sun 

• Some say the JBoss business model yields open source products, which 
are very feature-rich and robust, but with little online support, thereby 
creating the need for support contracts. 


Ajax3D and Rez are two tools that will allow DoD modeling and simulation to 
provide similar terrain capabilities to customers as the current industry leaders Google 
Earth and Nasa World Wind. A vast amount of research has already been done with 
regards to terrain modeling and the industry best practice is currently to overlay 
orthographic imagery on top of terrain data. The orthographic imagery is then “tiled” and 
processed by software into a proprietary (DirectX, OpenGL) or open source (X3D, 
VRML) format. The terrain software organizes the “tiled” orthographic imagery and 
outputs directories into the OS file system in a hierarchical fashion to minimize the 
server-side administrator’s maintenance worries but still take performance into account as 
well. 


E. X3D-EARTH, THE END-STATE OF X3D AND AJAX. 

Nothing scales like the World Wide Web. The end goal of all of the talk of Ajax 
and dynamic server-side state changes pushed to the client is a web based geospatial 
terrain system. X3D-Earth 19 is currently addressing these issues at NPS with the ultimate 
goal of providing the DoD with an open source terrain system. Currently at NPS, faculty 

I 9 X3D-Earth. Web3D Consortium X3D-Earth Home Page. 
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and students have been successful in generating 3D terrain models into X3D by utilizing 
the Rez tool. The next logical step might be to add the ability to layer various pieces of 
geometry; such as Google does with 3D buildings using 3D Warehouse 20 , though 
licensing issues apply in production, and various pieces of information on top of the auto¬ 
generated Rez terrain models. Below is AT&T Park, which is in a common format KMZ, 
or more commonly known as Google Earth version 4 format. Google Earth 4 currently 
supports KML and Collada and therefore a KMZ file is nothing more than a KML file 
and a Collada file in .zip format. The Collada zip file includes all geometry and textures 
organized in a sub directory structure so that the model looks strikingly impressive “out 
of the box.” The power of using a de-facto standard online repository for models of 
important city landmarks worldwide cannot be overstated. It allows the terrain system 
developer to quickly provide realistic looking models to their customers without having 
to reinvent the wheel. 


Goode r 

Search for: Models ^ Collections 


San Francisco, CA, USA > AT&T Park 

AT&T Park by Google 

Uploaded on August 11,2006 



See ratings and reviews 
4 ratings Rate this model 


Figure 13. AT&T Park 3D geometry available for download from Google’s 3D 

Warehouse from [20]. 


20 Google 3D Warehouse. Google. 
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Figure 14. Logo for Rez open source image slicer from the Rez Homepage. (2007). 
Retrieved August 11, 2007 from http://planet-earth.org/Rez/RezIndex.html . Rez is an 
orthographic image slicer that allows for orthographic imagery to be overlaid on top of 
X3D-Earth Terrain at various levels of detail to yield convincing city models. 


Rez is basically a tool that creates a mesh of orthographic imagery of any type 
(but for Geospatial purposes, from satellites) at various levels of detail; especially useful 
is Rez’s ability to mesh high-resolution urban orthography on top of elevation data such 
as Digital Elevation Map (DEM) or Virtual Reality Markup Language (VRML) Elevation 
Grid. Rez has two major modules: the imageSlicer and the Rez jar file itself. The image 
Slicer slices the orthographic imagery while the Rez jar takes care of the internals of 
meshing the sliced imagery to the elevation data. Rez creates Level of Detail (LOD) 
trees (either binary tree or quad tree) to accomplish the preceding. 



Figure 15. A Rez generated version of downtown San Jose in X3D at street level, 


showing details of HP Pavilion in Octaga Player. 
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Figure 16. A Rez generated version of downtown San Jose at altitude in Octaga Player. 


F. CONCLUSIONS 

Capt. Neushul’s work was truly innovative and a harbinger of things to come. In 
today’s society with the advent of mobile devices, the World Wide Web is the only time- 
tested and reliable way to provide an extremely scalable and maintainable application. 
However, the preceding is both a blessing and a curse in that whenever an application 
migrates from the client-server architecture of the past towards the three-tier architecture 
of today’s web based applications a myriad of considerations must be weighed. 

The most important of them is the choice of the MVC architecture. After that, the 
choice of presentation layer technology might follow with application server being the 
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last real concern to be addressed before a draft architecture proposal is brought to bear. 
Web 2.0 and Ajax have both improved and complicated the problem space by now 
allowing dynamic modification of graphs, both 2D (DOM) and 3D (scene graph). The 
challenge now lies with the program manager and contractor to agree on the appropriate 
set of frameworks for a specific application. As new open source enterprise-level 
frameworks are popping up every week, it is both an exciting and dangerous time to be 
involved in any enterprise-level project since making the right design decisions at the 
front-end of the development cycle is absolutely critical on the Java platform. 
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III. ASYNCHRONOUS JAVASCRIPT AND XML 


A. INTRODUCTION 

The term Ajax was first used by Jesse James Garret in 2005 21 and has now 
become so widely used that it was the topic of the majority of presentations at Java One 
Conference 2007 (Sun’s premier annual conference on Java Technology). This chapter 
describes Ajax on the architectural level and also provides a brief comparison of the 
different leading frameworks currently in industry. Additionally, a case study involving 
Legacy Bupers Access written enitrely in JavaScript is described to further underline the 
huge benefits that a Component-Driven Ajax design can provide the web developer. 
Finally, a real world application of Ajax for an NPS requirement will be shown. Ajax is 
a way to provide a rich-client experience, such as Google Maps, to the client. The 
preceding is accomplished by utilizing a new broker request called XMLHttpRequest and 
by keeping a server side copy of the client’s DOM. 

B. OVERVIEW 

In terms of Ajax, two approaches exist to creating the effect of dynamic server- 
side calls. The first is essentially a customized approach where the developer literally 
goes in and codes how the XMLHttpRequest object works by writing all the necessary 
code in JavaScript and either embedding it in the page or linking a reference to the script 
with a tag. The second and by far most popular approach to leveraging Ajax is to use a 
proxy framework, which lets the developer stay in Java while a framework that is sent to 
the client translates the Java into JavaScript and typically also takes care of issues relating 
to asynchronous communications as well. Such frameworks today include ZK, Direct 
Web Remoting (DWR), Echo2, Google Web Toolkit (GWT), Apache Extensible Ajax 
Platform (XAP), and Dojo to name a few. Every framework has its strengths and 
weaknesses, which are discussed later on in this chapter. 


Ajax (programming). (2007, June 1). In Wikipedia, The Free Encyclopedia. 
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C. ENCOMPASSING TECHNOLOGIES 

Technologies used in Ajax domain 22 are listed in Figure 17. 

• XHTML (HTML) and Cascading Style Sheets (CSS) for standards based 
presentation layer 

• Document Object Model (DOM) for achieving dynamic display and 
interaction 

• XML and XSLT for data interchange and manipulation 

• XMLHttpRequest for asynchronous data retrieval with the web server (in 
some Ajax frameworks an IFRAME is used instead of the 
XMLHttpRequest object) 

• JavaScript to manipulate and bind everything together 

Figure 17. A listing of the technologies currently in the Ajax domain from [22]. 

D. HIGH LEVEL AJAX ARCHITECTURE 

In the Figure 18, the uploading of the Ajax Engine to the client side is conveyed. 
Ajax Engines are typically fairly small (by broadband standards anyway, the GWT 
engine is approximately 100 kilobytes). The important thing to remember is that all Ajax 
frameworks require a footprint on the client-side, usually requiring a longer initial load 
time. Depending on the configuration and needs of the application the footprint can 
range from roughly 25 kilobytes to well over 500 kilobytes and beyond. However, 
typically Ajax footprints are approximately 100-200 kilobytes. The web developer must 
also keep in mind that many web servers support gzip compression, which help minimize 
the preceding footprint slightly. Intuition might suggest that uploading a translation 
engine for Ajax to the client can negatively impact performance. However, the preceding 
is actually a case of choosing the lesser of two evils. Compared with having to reload the 
page every single time the state changes on the client side, uploading the Ajax Engine is 
actually a significant architectural improvement that improves responsiveness. Figure 18 
is a high-level view of proxy-based Ajax architecture. 


22 Les Cardwell. (2005, December 30). AJAX-Bridging the Thin-Client Performance Gap. 
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Figure 18. A high-level view of proxy-based Ajax Architecture from Ajax Architecture. 
(2007). OpenAjax.org. Retrieved August 9, 2007 from 
http://openaiax.Org/member/wiki/images/c/c5/ClientSideAjax.gif . Note that the server- 
side Ajax engine is central to the architecture in that it serves as the intermediary between 
user-interface logic, typically written in Java and JavaScript on the client-side. 


E. WEB APPLICATION MODEL VS. AJAXIAN APPLICATION MODEL 

The classic web paradigm of a client soliciting data from the sever is kn own as 
“pull” and is synchronous in that any client-side process are “blocked” or must wait for a 
server-side response before continuing lines of execution. The new Ajax paradigm 23 is 
asynchronous which means that any client-side process does not need to wait for any type 
of server-side response before continuing to execute through code or tags within the 
presentation layer. There are several types of Ajax application models, classic Ajax 
Polling, Smart Polling, Asynchronous Polling, Long Polling, Streaming Ajax, True 
Push/Streaming, Forever Frame, and Reverse Ajax. Section F covers these types of Ajax 
in more detail. 


23 Ibid 22. 
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Figure 19. A classic web application model vs. an Ajax web application model from [23]. 
Note that in the new Ajax web application model XML is being passed from the server- 

side to the client-side via the Ajax engine. 



Traditional 

(Average) 

AJAX 

(Average) 

Performance 

Increase 

Performance 
Increase (°/o) 

Bytes Transferred: 

1,737,607 

460,799 

1,276,809 

73% 

Time (seconds): 

115 

78 

36 

32% 

Estimated 

Transmission time to 

US West Coast (56k) 
(seconds) 

293.45 

94.44 

199.01 

68% 


Figure 20. A performance comparison between Ajax and traditional web sites for a 

multimedia-heavy site from [23]. 
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F. TWEAKING AJAX AND EXTENDING IT WITH COMET 

Comet and Reverse-Ajax both attempt to tackle the problem of updating the 
client-side with server-side data in an efficient and scalable way. A good example of a 
real-world application where the server-side might constantly be updating the client is the 
classic stock ticker example. At first and, widely still in use, Ajax applications utilized 
polling over a discrete and un-dynamic timeframe to detect any sever-side state changes. 
From that point, Ajax Asynchronous Polling was created in order to eliminate wasted 
server-response cycles and mandated that the server-side only respond when the server- 
state actually changed. Comet and Reverse-Ajax attempt to go even farther by creating 
longer more persistent connections between server and client in a stateful non-traditional 
HTTP approach. 

Comet and Reverse-Ajax are two tenns that are mentioned frequently within the 
world of Web 2.0, and more specifically by Ajax web developers. Comet is a really the 
inverse of Ajax in that it is a design pattern that calls for sending asynchronous calls to 
the client, not the server as with Ajax. Depending on the client’s available bandwidth 
and specific requirements a specific brand of Ajax may be in order. By definition with 
Ajax asynchronous server-calls are a given; however, how often the server is challenged 
for updated state is up to the developer or project manager. Above and beyond the 
classic Ajax Polling paradigm, are methods such as smart polling, streaming (pushing), 
forever-frames, and Reverse-Ajax. 24 Figure 21 shows the classic page refresh web 
model, emphasizing that all of the waiting is done on the client-side. 


24 Alexander Alinone. (2006, December). Changing the Web Paradigm. 
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wait... 



reFesh a 


refresh 3 




user browser server 


Figure 21. Above is a diagram of the classic web page refresh model from [24]. Note 
that, the blue bars denote waiting time and all the waiting time is being done on the client 
and browser side. The client in this paradigm cannot perform any action during the form 

submission process. 


1. Ajax Polling 

Polling is a means of the server updating the information on the client at regular 
intervals or polls. Previously, using meta-refresh tags in a traditional Web 1.0 paradigm 
did this. However, in Ajax business is done on the client with JavaScript so in real- 
practice the intervals can be set with the JavaScript setlnterval() method. From that 
point, real-world information such as an RSS feed can be updated on a web page through 
such means. Weaknesses of a traditional Ajax Polling architecture are that scalability 
starts to become an issue if the polling time is set too low. In this scenario, the problem 
of updating the DOM with new information gets worse and worse as the rate at which 
information is changing is greater than the rate at which changes are being observed. The 
result is a architecture with clients that have outdated DOM trees and is slow at any 
substantial scale. Figure 22, is a diagram illustrating the interactions between client, 
server, and browser under the Ajax Polling scheme. 
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Figure 22. An Ajax Polling diagram from [24]. This diagram is showing the server 
passing data to the client over exactly the same discrete time-intervals. Note that in this 
model, the client can perform actions while waiting for the server to send its next update 

of information. 


2. Ajax Asynchronous (Smart) Polling 

Smart Polling is similar to Ajax polling only that the polling cycle has a variable 
period. Instead of polling the server at pre-determined times the client sends a request to 
the server. It is then up to the server to keep the request pending until new data is 
available, before sending the response back to the client. Upon receiving the response, 
the client sends an entirely new request. The preceding creates a paradigm where the 
polling timing is governed by the server and network latency. Figure 23 shows Smart 
Polling at the conceptual level. 
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Figure 23. A diagram showing Ajax Asynchronous Polling (Smart Polling) from [24]. 
Note that in this new model, the polling wait times are vary. In the asynchronous-mode 
polling reacts much better to network lag and server-load, making it a better solution if 

massive scalability is a concern. 

3. Streaming Comet aka (Server Push, Comet Forever-Frames) 

Streaming (Push) technology was first introduced in 1996, as a way of reversing 
the classic web model of pulling from the server. In a certain sense, email can be 
considered on of the Web’s oldest push technologies. In the streaming model, the client 
receives updates from the server-side at the server’s discretion in the form of a 
continuous feed. In the Ajax model shown in Figure 24, the client becomes a passive 
entity receiving updated information as soon as it is available on the server, without 
having to periodically ask for it. Streaming Ajax depends on a long-lived HTTP 
connection to the server in order to receive updates from the server based on event- 
registration techniques such as standard event handling. As soon as a state change occurs 
the server pushes the new data to the client and flushes the output stream but does not 
close it. In this pattern, the browser then resolves the differences between the client-side 
DOM and the server-side DOM. 
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Figure 24. A diagram of Streaming Ajax or Comet technology from [24]. In the 
diagram, the client and server establish a long running connection to monitor state and 
update each other upon state changes. Note that this technology is still largely 
experimental and might pose some scalability problems. Also note the absence of any 

wait time. 


4. Comet Long Polling 

Long polling is very similar to Ajax streaming except that the connection actually 
closes. Long polling is basically a bandwidth cheaper version of Ajax Streaming in that 
it keeps a long connection but not a persistent connection. In Long Polling, the Ajax 
application will only send out a single request and wait for partial responses, i.e., chunks 
of data to come back from the server. Long polling is recommended over normal 
unresponsive polling but only if the Ajax application in question does not require 
frequent updates. If frequent updates are of a concern, then Ajax Streaming can be 
utilized. 


G. COMPARISON OF LEADING AJAX FRAMEWORKS 

While many of the leading Ajax frameworks do agree that Ajax can abstract away 
JavaScript from the server-side developer they all fundamentally have different views 
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regarding how much more a decent Ajax framework can do. The domain of Ajax 
frameworks is basically split into three camps. The first camp thinks that Ajax 
frameworks need to “do one thing and do it well.” Google Web Toolkit 25 falls squarely 
into this camp and is designed from the ground-up to push more computation to the 
client-side. The second camp thinks that an Ajax framework needs to be server-centric 
and possess a large variety of rich widgets each with inherent properties like self¬ 
validating fields and native data binding properties. ZK 26 , Echo2 27 , and ICEfaces 28 fall 
into the second camp. The third and final camp believes that an Ajax framework can do 
as much as possible including libraries for remoting, validation, offline-browsing, and 
security. The Dojo 29 and Apache XAP 30 Projects fall under the third category. Figure 
25, shows the first of many Ajax frameworks whose pros and cons are evaluated in this 
chapter. 


ZK 



Figure 25. A screenshot from [26]. ZK is a good choice for a proxy-based Ajax 
framework in that it has a lot of support. ZK is currently the most downloaded Ajax 

framework on SourceForge.net. 


25 Google Web Toolkit Project Home. Google. 

29 ZK Project Home. ZK Ajax Framework. 

27 Echo2 Project Home. Echo2 Ajax Framework. 

28 ICEfaces Project Home. IceSoft Technologies. 

29 Dojo Project Home. Dojo Ajax Framework. 

39 Apache XAP Project Home. Apache Software Foundation. 
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ZK Pros: 


ZK Cons: 




Lots of widgets 

Easy to understand tag libraries and xml namespaces 
JavaScript generated by a ZK engine, developers stay in Java 
Intuitive framework, working example in less than one hour 
Supports Java Server Faces technology 
Contains libraries for application on Mobile Devices 
#1 Ajax Project on SourceForge.net 

Need to learn Mozilla’s Extensible User Interface Markup Fanguage 
(XUL) 

Dual license structure just like MySQL 



Figure 26. The logo for the Dojo toolkit framework from [29]. The Dojo toolkit provides 
the developer with rich libraries for everything from security to server-side push. 


Dojo Pros: 

• Wishes to be the “Java” i.e., one stop shopping for Ajax technologies 
offering libraries for all aspects of Ajax from security to offline browsing. 

• Rich libraries of Ajax widgets and features, i.e., server-side push 

• Offline browsing 

• Sun support 


Dojo Cons: 

• Wishes to be the “Java” i.e., one stop shopping for Ajax technologies 
which means that it has a larger footprint than many other frameworks 
since the Ajax bridge needs to do so much more. The Dojo framework 
will also never benefit from the simplicity in scope that typically makes 
for great software projects, which adhere to the adage of “do one thing and 
do it well.” Dojo serves as a contrast to a minimalist framework such as 
GWT. 
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Figure 27. The logo for Google Web Toolkit from [25]. Google Web Toolkit takes a 
client-centric approach to providing Ajax functionality to the user. 
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igure 28. A representation of the Google Web Toolkit (GWT) architecture from [30]. 

Note that in the GWT architecture, more emphasis is put on utilizing the client-side. 
Compared to other proxy frameworks such as ZK or ICEfaces, GWT has relatively few 
widgets, but the ones it does have are robust. 31 


GWT Pros: 

• Back to basics approach to widgets, do one thing and do it very well 

• JavaScript generated from GWT Engine developers stay in Java 

• Google support 


GWT Cons: 

• Low number of widgets 


31 Dion Hinchcliffe. Google’s Innovative Yet Limited Ajax Environment. 
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Non-intuitive layout of core JavaScript libraries. 

No working example, after two days still no working example 






?xap 

Figure 29. Logo for the Apache XAP Project from [30]. Note that Apache XAP suffers 
from a small user base and inadequate examples and documentation. 


XAP Pros: 

• Project related approach to Ajax good if familiar with Ajax 

• Uses Dojo as its default toolkit 

• Nexaweb support 


XAP Cons: 

• Many in industry claim it attempts to reinvent the wheel by creating a new 
UI declarative language called XAL which is strikingly similar to XUL 
the one already accepted by industry and supported by the Mozilla 
Foundation 

• Few demos 

• Name Recognition still fairly low 

• Documentation considered weak by many developers thereby creating 
very shallow learning curve 


echo2 


Figure 30. Logo for Echo2 framework from [27]. Echo2 has an Ajax engine that allows 
for the developer to not only stay in Java but to program to the Swing API on the server- 
side and have the results be translated on the client-side to JavaScript. Echo2 is a good 
choice if developers within the enterprise are very comfortable with Swing. 


Echo2 Pros: 

• Swing based framework great for developers that want their web pages to 
look like Swing apps and still be using Ajax under the hood. Great for 
clients that want web applications so robust that the users do not realize 
they are on the Internet 

• JavaScript generated from Echo2 Engine allows developers to stay in Java 
without worrying about the implementation details of JavaScript 
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Echo2 Cons: 


• No broad based industry support. Hardly mentioned (heard it once) at 
JavaOne 2007 



Figure 31. Logo for Java ICEfaces from [28]. Java ICEfaces is another Ajax proxy 
framework that is meant to integrate with (JSF) Java Server Faces technology. Since, 
JSF is a Sun standard JSF is growing in popularity and most Ajax frameworks are being 
built with JSF compatibility in mind from the ground up. 


ICEfaces Pros: 

• Architecture intended to be laid on top of Java Server Faces (JSF) which 
has Sun support (Supports JSF 2.0) 

• Level-4 framework, denoting support for service-oriented architectures 

• JSF is currently integrated into NetBeans 6, so if developers are already 
using the IDE it will integrate nicely 

• Wide industry acceptance with such high profde customers as SAP, 
Boeing, HP, IBM and Avaya. 

• Open Ajax Hub (Industry supported Ajax Consortium) Compliant 32 

• Integrates nicely with the new JBoss Seam Java Enterprise Edition (EE) 
version 5 framework 

• Lots of demos 33 . 


Supports drag-and-drop components (key for smartphones with touch 
controls like the iPhone) 34 . 


ICEfaces Cons: 

• Associated learning curve with using the JSF Framework 


32 Open Ajax Alliance. (2007). Open Ajax Hub FAQ. 

33 ICEfaces Auction Monitor Live Demo. (2007). IceSoft Technologies. 

34 ICEfaces Component Showcase. (2007). IceSoft Technologies. 
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Figure 32. A great ICEfaces demo of an online auction from [33]. The demo shows 
dynamically changing bid times and time remaining (shown at JavaOne 2007). 


Demonstration Description Source 

Drag and Drop each item's respective icon to the cart icon to add it to the shopping cart. 

Press the "Return" button on each item to remove it from the cart. 


Store Cart 

Image Name Price Quantity Image Name Price Quantity Cost Return Item 



Figure 33. A nice shopping cart Ajax drag and drop control demo in Java ICEfaces from 
[34]. The Ajax drag and drop functionality might prove useful in a future X3D-Earth 
implementation allowing for features such as place mark additions. 
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H. CASE STUDY: LEGACY BUPERS ACCESS FROM NAVAL 

PERSONNEL COMMAND 

At Naval Personnel Command back in 2004, this author was tasked with 
responsibility of Bupers Access, which is now Bupers Online. The site was initially put 
together by a few technically savvy Navy Chiefs and was turned over to me by an ex- 
DT1 who was an IT1 at the time. Also at the time, Legacy Bupers Access had tons of 
JavaScript literally embedded in the presentation layer, in direct violation of good MVC 
practice. Particularly painful was the fact that many of the date box controls were done 
in pure JavaScript and were pages long. During my tenure as the system administrator, 
orders from supervisors to change content were frequently given but not executed 
because of the complexity of the JavaScript being on the order of pages of code for one 
component such as a date box. However, with Ajax components, DoD can abstract the 
complexity out of JavaScript and still leave the developer in their comfort zone in Java. 
Furthermore, by using Ajax methodologies in new web development projects, the DoD 
can leverage the power behind the Web 2.0 concept and have the potential to do some 
rather astounding things like offline browsing which can be absolutely critical in some 
operational contexts. 

I. EXAMPLE AJAX APPLICATION: MOBILE DEVICE CHECKOUT 

The following is an exemplar on how an actual requirement at NPS, specifically 
within the Computer Science department was tentatively addressed using Ajax 
technology to the point that a prototype web application was developed and is currently 
awaiting testing. Currently, the Mobile Devices Lab at the Naval Postgraduate School is 
in need of a system that tracks checked out PDAs, Books, and Software. Through the 
usage of Ajax technology, such a system was created and now only needs to be populated 
with accurate inventory information to be tested before being ultimately put into 
production. ZK was chosen as the Ajax framework due to the relatively friendly learning 
curve and the abundant amount of community support, user-examples and widgets. The 
Mobile Lab wanted a system that the average student can maintain and minimal 
complexity within the presentation layer. Figure 34 is a screenshot of the login page: 
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Mubile Web Checkout Application 

Email 


Password. 


LoginJ 
btew User'- 1 
Forgot Pas sword 3 

Figure 34. The login screen for the Mobile Web Device Checkout application. The Ajax 
application was implemented in ZK with a PostgreSQL database as the back-end and 
Apache Tomcat as the application server. 



■ 

Welcome to .Mobile Checkout \-f 



Figure 35. The Main Menu screen for the Mobile Web Application. Note that the links 
for Access Reports and View Cart both have Ajax ZK controls powering them. For 
Access Reports a ZK paginated data grid is utilized. For the View Cart functionality, an 

Ajax date box and data grid are utilized. 
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Mobile Checkout Admin Window 


| View All Checked Out Hems 


View Checked Out Items Map 


username 

itemjd 

item desc 

qty 

itemjype 

returndate 

checkoutjimestamp 

r mafarias@nps.edu 

18147 

verizon treo 

5 
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2007-03-21 

2007-03-01 

15:55:58,046 

r mafarias@nps.edu 
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verizon treo 

2 
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2007-03-22 

2007-03-01 

15:55:58,203 

r mafarias@nps.edu 
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C#,NET Mobile Programming 

2 

book 

2007-03-08 

2007-03-01 

16:01:00,656 

r mafarias@nps.edu 

18146 

hp ipaq 

1 

pda 
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2007-03-01 

16:01:34 

r mafarias@nps.edu 

18151 

Windows Vista 

1 

software 

2007-04-13 

2007-03-01 

16:02:27,812 

r mafarias@nps.edu 

18147 

verizon treo 

1 

pda 

2007-03-09 

2007-03-02 

11:01:54,804 

r mafarias@nps.edu 

18147 

verizon treo 

1 

pda 

2007-03-15 

2007-03-02 

11:32:13,663 

T mafarias@nps.edu 

18147 

verizon treo 

1 

pda 

2007-03-14 

2007-03-05 

11:42:54,828 


Print Report 

Email Report 

Send Late Notice(s) 

Mark Checked Item(s) As Returned 




Figure 36. A ZK tab panel containing a ZK data grid. Note that this Ajax control 
contains paginated and sortable columns inherently. The benefits of using Ajax 
frameworks are that components frequently support the preceding features and more 

natively. 
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Figure 37. A ZK date box control within the View Cart module of the application. Note 
that this control typically takes approximately hundreds of lines of JavaScript to 
implement without Ajax. With Ajax this control takes two lines of code and also has 
built in validation and constraints such as not allowing the input of dates in the past. 
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figure 38. An automatic date box validation example with ZK date box control. Note 
that the “in the box” validation that occurs is native to the control and requires no extra 
programming. This diagram shows the error message that automatically pops up if the 
user enters erroneous data into the date field at checkout time. 


The approach of the project was to utilize as many built-in Ajax widgets as 
possible and to stand the application up for initial beta testing as soon as possible. An 
elementary MVC framework was utilized in this project for the sake of not overwhelming 
any potentially interested students as was requested by the sponsor. The sponsor also 
required the exclusive usage of open source technologies. The web application was 
developed in the NetBeans 5.5 IDE running on Apache Tomcat 5.5. The web application 
utilizes PostgreSQL 8.1 for data storage. All of the preceding applications are open 
source under the LGPL (Lesser-GNU Public License). 

Noteworthy aspects of the application are the fact many widgets, date box and 
sortable table, in this project specifically are packaged as components. Furthermore, 
nearly all of the controls have validation schemes built in, note the “No Past, and No 
Empty Constraints” for the date box in Figure 39 below. The preceding allows for easy 
development on the server-side. With the date box in particular the old way of doing 
business required multiple lines of code. Worst of all was that due to the JavaScript 
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technology, before Ajax came along, all the JavaScript code was oftentimes heavily 
imbedded in the presentation layer. The following lines of code, which are really two 
lines of code but spread out for readability sake, are exactly the lines of code required to 
utilize date box in the presentation layer. 


<jsp:directive.page import="org,zkoss.zk.ui.util.*"/> 

<x:datebox name='<%=returnDate + index %>' 
id = 1 <%=returnDate + index %>' 
constraint="no empty, no past"/> 

Figure 39. The Ajax code to display a date box with a “no past” and “no empty” 
constraints using the ZK framework. Note that this code replaced a 565-line legacy date 
box implementation that is presented in Appendix C. 


Contrast the above code snippet with the old way of doing business (see 
Appendix C) for full legacy date box code. The code is a total of 565 lines 35 . From both 
a developer and project manager perspective, whittling down something that used to take 
565 lines into something that now takes two lines is a huge win. From the business 
object developer perspective, it is a huge win with regards to time. From the project 
manager’s perspective it is a huge win with regards to maintainability. Coupled with the 
fact that all 565 lines might be in the presentation layer and can possibly overwhelm the 
layout minded web designer and adversely impact their productivity as well; the 
dichotomy is even clearer and more powerful. Current Ajax proxy frameworks give the 
project manager tightly integrated control of JavaScript files. 

The various popular Ajax frameworks promote efficient management of the 
JavaScript, which was really what was missing in 1997 when Dynamic HTML (DHTML) 
created a spark and was quickly put out by a lack of interested developers. DHTML also 
lacked any efficient way to apply its impressive graphics abilities without page refresh, 
which quickly became annoying to most developers as well. Ajax picks up where 
DHTML left off with the new XMLHttpRequest object and its inherent ability to contact 
the server-side whenever it needs to. An Ajax component approach versus pure 
JavaScript is clearly the way to go in Web 2.0. Furthermore, a proxy based framework 
approach versus custom-made calls to XMLHttpRequest is also the direction of the 


35 Serge Ryabuck. (2002, January 9). Legacy JavaScript DateBox Code. 
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future. Just as with MVC, modern day Ajax proxy frameworks keep the developer from 
creating an obfuscated code base and minimize scripting in the presentation layer. 

J. CONCLUSIONS 

Ajax has definitely become a buzzword in the realm of enterprise web 
development. It is important to remember that the amount of server-centric or client¬ 
centric activity inherent in a web application must dictate the choice of Ajax proxy 
framework, not the other way around. Also, the important thing to realize is that while 
Ajax is an outstanding new technology, it is not a panacea for curing poor web design, 
performance, maintainability, or scalability. It is critical that Ajax be used in moderation 
and only be applied to actual requirements and not for the novelty of just implementing a 
Web 2.0 application. In fact, Ajax is a double-edged sword in that the developer needs to 
be careful with regards to how much JavaScript is going over the wire as not to produce 
too much latency for the end-user. The preceding is discussed further in the Ajax 
Performance chapter. The important thing to take away from Ajax is to remember the 
tenn is conceptual. The various frameworks explored in this chapter attempt to give the 
reader quick insight as to how different requirements can be mapped to the domain of 
Ajax. Built on a strong foundation of an appropriate Ajax framework selection, and a 
suitable MVC architecture, rich-client experiences can be had on the GIG allowing 
people to work more effectively and create the applications they need now and not at a 
later date when NMCI feels like completing the VV&A (Verification Validation and 
Accreditation) process. 


49 



THIS PAGE INTENTIONALLY LEFT BLANK 


50 



IV. AJAX PERFORMANCE 


A. INTRODUCTION 

One of the more annoying features of new technology demonstrations is the fact 
that it is almost never the case that the vendor, or in the case of many open source 
projects, the consortium or working group, discusses the pros and cons of utilizing the 
new technology in question. While Ajax has myriad benefits, if used incorrectly, Ajax 
can be a performance bottleneck due to a large Ajax Engine or an improper technology to 
requirements mapping i.e., using JavaScript Object Notation (JSON) when the browser 
that clients use is more efficient with Extensible Style Sheet Transformations (XSLT). 
Furthermore, with the rise of mobile smartphones the application of Web 2.0 constructs is 
likely to become increasingly important as the growth of Web-aware mobile devices 
begins to saturate the marketplace. This chapter will attempt to address the currently 
identified Ajax performance issues within industry and offer possible best practices for 
design of Ajax enabled web applications. 

B. OVERVIEW 

At the high level, Ajax perfonnance optimization seeks to accomplish two things. 
The first is simply minimizing direct manipulation of the DOM. The preceding is done 
with Ajax engines in general, or innerHTML calls if the application is implementing Ajax 
calls manually. Minimizing dot notation on subsequent client-side calls to the DOM is 
also important as there is a level of JavaScript optimization in play across different 
platforms but their degree varies. Secondly, the developer must seek to minimize the 
amount of JavaScript coming across the wire to the client from the server. The developer 
must always keep in mind that JavaScript is about 5000 times slower than a typed 
language such as C 36 . Additionally, common questions when approaching performance 
optimization include but are not limited the items in Figure 40. 


3 ® Geoffery Fox. (1999). JavaScript Performance Issues. 
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1. How much data the enterprise must handle? 

2. What type of data? 

3. How many server hits? 

4. What are the common workflows? 

5. What browsers are clients using? 

6. What is the existing infrastructure? 

Figure 40. A list of baseline questions to consider when addressing Ajax performance. 

C. JAVASCRIPT COMPRESSION 

With regards to Ajax, it is important to remember that JavaScript files are actually 
being dynamically sent over the wire to the client via the Ajax engine. Furthermore, the 
Ajax engine itself requires a small footprint (typically on the order of 100-200k), again 
over the wire. From the preceding, compression and consolidation become necessary 
methods of improving performance if necessary for the web application in practice. 

Since the HTTP 1.1 specification came out, Apache and Microsoft IIS (Internet 
Information Server) both support zipping the JavaScript via gzip. Another methodology 
to improve perfonnance might be to write a Combiner Servlet to dynamically combine all 
the .js files at run time. The preceding is applicable even if the Ajax framework you are 
currently using utilizes an Ajax engine on the client-side. However, if it does not the 
method is extremely critical. Furthermore, the Combiner Servlet can also incorporate any 
imagery or Cascading Style Sheets (CSS) 37 that are involved in the presentation layer at 
runtime further saving bandwidth and ameliorating response times. 


37 Craig Baker. (2007, May 16). Ajax Performance Tuning. 
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Original 

Size (Kb) 

9.3 


Minify 

3.9 

GZip / Deflate 

2.8 

Minify + GZip / Deflate 

1.3 


? Reduction 

86% 




Figure 41. A summary table showcasing from [38]. In the figure, several types of 
JavaScript compression and their expected result on a 9.3-kilobyte file. 


D. MINIMIZING WHITESPACE AND OTHER TRICKERY 

Within the actual code itself, there are a few things that the developer can do to 
minimize the transmission time of the JavaScript across the wire 38 . In the JavaScript, the 
developer can eliminate white space and new line characters. However, the drawback of 
the preceding methodology is that it obviously drastically reduces readability and 
maintainability of the code. The developer can also configure the cache settings in the 
HTTP Response headers appropriately. Native DOM parsing in the browser and by 
Image Merging 39 or splitting an image into two for faster transmission across the network 
can significantly increase perfonnance. Figure 42 shows the details of Image Merging. 


38 Dave Johnson. (2007). Pragmatic Parallels: From Development on the Java Platform to 
Development With the JavaScript Programming Language. 

39 Ibid. 
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Figure 42. Image Merging Process from [38]. In the figure, the breaking up of imagery 
into smaller sections for faster traversal over the wire is shown. 
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Figure 43. An example of Image Merging at the presentation layer from [38]. 
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E. AVOIDING EXPENSIVE JAVASCRIPT METHOD INVOCATIONS 


Another critical requirement for successful Ajax performance optimization might 
be knowing the details of the implementation of the code base along with the details of 
the customer base. Code implementation details come into play when trying to weed out 
CPU-intensive JavaScript calls. Figure 44 shows a table of some of the more egregious 
JavaScript offenders 40 and minimizing this approach can only help the cause. 


qetOff&etTao 

gstRnK 

SBlCbsaNums 

geiStyleflheeH 

setBac^gnwjTclGoiof 

getStyle 

gfltQjiFwNamfi 


Expensive JHVHScrlpt MrL hml Calls 


175 


350 


525 


700 



Time (ms) 


Figure 44. A chart showing the most CPU-intensive JavaScript methods after [38]. 


F. KNOW THYSELF KNOW THY BROWSER 

Knowing the browser platform that the customer base primarily uses is of critical 
importance. String comparisons in IE are generally about four times slower than those in 
Firefox. 41 Reverse-Ajax or Comet technology is also an option to allow for graceful 
degradation of the web application in conditions of low to zero bandwidth if the customer 
base is forward deployed or in remote locations. Knowing that XSLT, in general, 
performs better in an Internet Explorer environment is also critical to success in 
optimizing performance. JavaScript and associated technologies such as JavaScript 

40 Dave Johnson. (2007). Pragmatic Parallels: From Development on the Java Platform to 
Development With the JavaScript Programming Language. 

41 Ibid. 
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Object Notation (JSON) typically run faster in Mozilla Firefox. If using XSLT, it is also 
beneficial to know that for faster XSLT typically avoid using <apply-templates> and 
gravitate toward <for-each> tags. Interestingly enough, the XSLT processor actually 
takes longer to find the templates than to iterate through the for-loops. The preceding 
process will also yield a side benefit of reducing file size. Furthermore, to improve 
performance minimize “*” or “//” queries in XPath. Finally, it is good practice to 
maximize the usage of the <xsl:key> tag lookups with name value pairs to minimize seek 
times. Figure 45 shows the significant difference between processing times of XSLT 
between IE and Firefox. 


XSLT Cross Browser Performance 



Figure 45. A diagram showing Internet Explorer’s better XSLT performance when paired 
against Firefox (lower times are better). After Dave Johnson’s slides, [38]. 
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G. CONCLUSIONS 

The usage of Ajax Web Applications (Web 2.0), on mobile devices is clearly a 
disruptive technology. With Apple’s new release of the iPhone and the entire mobile 
industry copying that design, the concept of the “Web in Pocket,” will only gain 
momentum in the near future. Owing to the preceding, Web 2.0 applications need to be 
designed with performance and scalability in mind. Currently, Google Maps works 
beautifully on the iPhone even on AT&T’s EDGE network. The performance of Google 
Map’s as an Ajax application on modern day smart phones is a testament to the power of 
Ajax and the power of good Web 2.0 design principles. In the future, if a server-side 
version of X3D-Earth were to become a reality, performance over mobile devices can be 
a critical consideration to be able to empower the service member while they are forward 
deployed. The ability to visualize the same battle space on a smart phone that U.S 
Central Command (CENTCOM), or North American Aerospace Defense Command 
(NORAD) can visualize on their gigantic LCD Monitors is the end game of this 
endeavor. 
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V. AJAX SECURITY 


A. INTRODUCTION 

Through the downloading and execution of code from the server-side the client 
obviously accepts a certain level of risk. The goal of Ajax security is to minimize that 
risk in a cost-effective manner that makes sense for the enterprise. As many Navy 
employees are now realizing, with the NMCI network, sometimes too much security is a 
bad thing. However, the preceding does not advocate lax security either. Aristotle had a 
good handle on things when he declared that the key to life was to live the “Golden 
Mean.” By Golden Mean, Aristotle meant that typically in life people run into problems 
when their life is not in balance, i.e., too much work and no family-time or vice versa. 

The usage of optimal computer security techniques works in the same way. In this 
chapter, several methods of minimizing the new security concerns associated with using 
JavaScript in the enterprise to power Ajax. Concepts in this chapter include the Sandbox 
Concept, Server Of Origin, Cross Site Scripting (XSS), Cross Site Request Forgeries 
(XSRF), and Mashup concerns. On top of the preceding, a few real world examples of 
security breaches will be examined for the sake of future prevention. 

B. OVERVIEW 

The fear of Identity Theft has discouraged lots of users from using many aspects 
of the web. It is in the best interests of the project lead or program manager to ensure that 
the end-user has an acceptable level of information assurance on their own respective 
web architectures. As stated in the introduction above, the key is to not pigeonhole the 
end-user into a situation where there is so much security that they cannot perform routine 
tasks with acceptable speed and convenience. A balance must be struck between security 
and sanity. Ajax controls can help and hurt the enterprise in this regard. Oftentimes, 
sites will have draconian password constraints on new registrations or accounts that are 
more constrained than banks and online trading sites. The preceding is absolutely 
ridiculous at times for sites where the worst an end-user can do is post a message on a 
blog or gain access to read-only data. A far better solution might be to utilize an Ajax 
password widget, which can give the user instant feedback on the strength of their 
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password while at the same time implementing reasonable password lengths and rules. 
Such widgets already exist and can be seen on Google 42 when you sign up for a new 
account. The functionality is shown in Figure 46 for the reader. 


Required information for Google account 

Your current email address: 


e.g. myname@example.com. This will be used to signdn to your 
account. 

Choose a password: 

. Password strenath: Strona 

Re-enter password: 

Minimum of 6 characters in length. 



2! Remember me on this computer. 


Creating a Google Account will enable Web History. Web History is a 
feature that will provide you with a more personalized experience on 
Google that includes more relevant search results and 
recommendations. Learn More 

0 Enable Web History. 


Figure 46. A new Google account sign-on registration form from [42]. The form 
showcases an Ajax password strength widget. Also note how a password of minimal 
length can still be considered strong depending on the characters used. 


Unfortunately, Ajax brings with it security issues with scripting. Any time code 
is streaming either into the client or into the sever-side issues will come up. The 
preceding is as inevitable as death and taxes. However, while the Ajax approach is not 
inherently insecure, it is surely not inherently secure. Steps must be taken by the project 
lead to ensure that an Ajax-enabled site is not compromised. The good news is that the 
preceding truth applies to all web applications in general. Buffer overflow attacks and 
script injection attacks of all sorts affect all of the platforms from Java Enterprise Edition 
(EE) to .NET. 

C. SANDBOX CONCEPT (“SERVER OF ORIGIN”) 

The Sandbox Concept or “Server Of Origin” concept states that no JavaScript 
code will be executed on the client if it originates from a web site that lies outside both 

42 Google Login New User Registration Page. (2007). Google. 
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the port and domain of the originating server. More specifically, on top of the domain 
constraint, the Sandbox enforces that the server of origin matches port of origin as well, 
so an Ajax call from port 80 cannot interact with one at port 8080 for instance. 
Furthermore, because of the Sandbox, JavaScript is not permitted to perfonn any file 
(I/O) Input/Output. The preceding restriction makes sense for several reasons. The client 
might not want a compromised machine to contact it posing as a legitimate web site and 
sending it malicious code to execute, which might alter or steal local files. This 
“Sandbox” is good for security but bad for Mashups like HousingMaps.com that require 
cross-site scripting. To circumvent the Sandbox constraint, typically, Web Services that 
need to leverage Mashups must utilize a 3 rd party proxy (servlet) at the sever-side to 
contact and retrieve the relevant data and then have the server of origin deliver the new 
data to the client. The preceding is obviously not a bulletproof security pattern but at the 
program manager level, the decision of whether to implement a Mashup needs to take 
this into consideration nonetheless. 

D. CROSS SITE SCRIPTING (XSS) 

Cross Site Scripting (XSS) is essentially a child of the fairly new but now widely 
adopted method of attack called script injection. Script injection is not unique to the 
Web, or even Ajax, since it has been around for years and can occur with traditional 
desktop apps and even extend to the database with SQL injection attacks. Script injection 
attempts to have the victim machine execute code by overloading buffers in unprotected 
strings coming from user interface (UI) textboxes, web textboxes (HTML, .NET, Swing, 
Ajaxian DHTML, or even URLs which pass parameters to servlets. Microsoft and Sun 
have gone a long way to prevent script injection by deprecating older methods that 
allowed for buffer overflow in the past but the problem is far from extinct. An XSS 
attack injects a script into the page delivered to the client shortly before their web 
browser renders it. Once the machine has been compromised various bad things can 
happen such as cookie theft, session hijacking, keystroke logging, screen scrapes and 
Denial of Service (DoS) attacks. Furthermore, with Ajax and its ability to 
asynchronously call the server-side transparent to the client the power of XSS attacks has 
increased in potential. No longer does the XSS have to passively gather screen scrapes or 
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wait for users to issue commands. With Ajax, the XSS Attack can send multiple 
asynchronous calls to the server-side without the client noticing. 


E. DISCUSSION OF SAMY WORM 

In 2005, the first usage of an XSS based Ajax attack was observed on MySpace. 
This new attack was called the Sarny Worm 43 and was extremely viral, infecting millions 
of machines within hours. Sarny was a user-profile on MySpace that had been 
compromised by utilizing XSS. When viewed, Sarny added the viewer to the Sarny 
friends list. Furthermore, the worm infected the client machine itself; in effect creating 
it’s own Sarny. Within 20 hours the Sarny Virus had spread to a million machines 
becoming infamous as one of the fastest spreading viruses ever. Technically speaking, 
the Sarny Worm introduced a technique of appending strings into disallowed JavaScript 
keywords to accomplish its end state. Myspace actually disallowed many of the 
keywords such as “onreadystatechange” and “innerHTML” that the Sarny Wonn used to 
propagate itself. However, by dynamically calling the preceding method with String 
manipulations (concatenations and appends), the worm was able to circumvent 
MySpace’s security scheme. 44 The XSS portion of the attack came from the fact that 
profiles under the MySpace enterprise can be accessed using two different domains, 
profiles.myspace.com and myspace.com. Figure 47 shows the general idea. 


if (location.hostname == 'profile.myspace.com') document.location = 
'http://www.myspace.com' + location.pathname + location.search; 

Figure 47. XSS attack code from [44]. The code shows changing domains so that the 
malicious JavaScript can satisfy the constraints of the Sandbox. From this point, a POST 
was called which added the wonn to the users friends list. 


This new type of worm, the Ajax worm first appeared in 2005 and has 
subsequently appeared again and again on the big Internet. In 2006, Yahoo got one 
called Yamanner, which affected its email system by sending a copy of itself to the 
compromised machines contact list. 

43 Samy (XSS). (2007, June 22). In Wikipedia, The Free Encyclopedia. 

44 Technical Explanation of the MySpace Worm. 
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F. CROSS SITE REQUEST FORGERY (XSRF) 

A Cross Site Request Forgery 45 is a malicious attack going in the other direction 
(client to server). In the preceding attack, the XSS was really an attack on the client as 
the agent of infection injected code into the client web page to be rendered and then 
executed. Cross Site Request Forgery (XSRF) aims to take advantage of an inherent trust 
between a Web Service and Web Browser by issuing illegitimate requests on the client 
side. The preceding trust normally comes in the form of a cookie stored on the client 
machine that has yet to expire. XSRF attacks are sometimes known as “riding the 
session” as well. The client is typically tricked into clicking an image with a URL tag 
that POSTs to an enitrely different website, a bank for instance. The victim in this case 
might have a back up layer of protection with referrer headers sent to the server-side. 
However, many users disable referrer headers due to privacy concerns, ala “Big Brother.” 
In this type of attack, typically JavaScript is embedded within the <script> tag of page. 
Counters to XSRF include having the server only respond to HTTP POSTs since the 
<script> tag utilizes HTTP GET to do its work 46 . However, the preceding is also 
problematic in that GET is optimized for performance. Various Ajax-based frameworks 
tackle the preceding problem differently. Amazon quickly found out that XRSFs can be 
dangerous and currently counters the problem of session riding by forcing re¬ 
authentication of the session at various critical points within the enterprise such as users 
changing shipping address for instance 47 . In general, the preceding is effective against 
XRSF attacks. Figure 48 shows a comprehensive listing 48 of how secure various Ajax 
frameworks are “out of the box.” 

G. PREVENTION OF ATTACKS 

Now that the various techniques for getting to the JavaScript with malicious intent 
have been discussed, the next obvious question is how are attacks prevented? There are 
two schools of thought with regards to preventing JavaScript attacks. The first is to 

45 Cross-site request forgery. (2007, July 6). In Wikipedia, The Free Encyclopedia. 

46 Jeremiah Grossman. (2006, January 27). Advanced Web Attack Techniques Using Gmail. 

47 Chris Shiflet. (2007, March 15). My Amazon Anniversary. 

48 Dave Crane, Darren James, and Eric Pascarello. (2006). Ajax in Action. 


63 



decline malicious requests altogether. The second is to process the request but to prevent 
execution of the JavaScript response. One of the most effective ways to deter a 
XSS/XSRF attack is to use some type of transient authentication scheme instead of a 
persistent one like Cookies or HTTP Authentication. By transient, typically what is 
meant is to keep the attacker guessing. A popular way of achieving this end is to 
incorporate the current user’s SessionID into the URL. A similar approach might be to 
include a user-specific token in HTTP Requests to be validated in addition to the client- 
side cookie. With Ajax requests, the double submission concept is also very effective. 
With the preceding, the stricter of the two cross-domain rules is adopted and enforced. 

When Gmail was compromised by Jeremiah Grossman in 2006, he utilized XSRF 
but with a twist. What Grossman basically did was email the victims a link to an off 
domain site, assuming they were logged in if they were reading their email. By clicking 
the link, the victim sent an off-domain HTTP request that also contained the session 
cookies such as the request and response variables. In the response variable, the contact 
list was stored as an unreferenced array to be parsed at runtime. When JavaScript parses 
the array it calls the Array() method. Grossman basically overwrote the Array() method’s 
constructor with his own malicious code, which iteratively looped through the stolen 
contact list. Two lessons can be learned from this attack. The first is not to put any 
sensitive data or sensitive business logic inside JavaScript. At the very least, wrap the 
HTML tags around the data to prevent it from being accessed by script tags. Secondly, if 
the JavaScript files must contain sensitive data make the urls unpredictable or ensure that 
the file cannot be accessed by an off-domain referrer. 

To prevent an attack such as Grossman’s what is needed on the server-side is to 
prevent direct execution of the response. To do this the client needs to keep in mind that 
it is clearly within their bounds to modify any data they receive before executing it. 
Therefore, when the server sends out data during a response it will typically prefix or 
suffix the data with something that will trick the attacker by stifling the JavaScript 
Compiler. A perfect example of a prefix that might do the preceding can be while(l) 
which can immediately stop any ahack progress and place the JavaScript compiler of a 
unauthorized client into an infinite loop. 
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The second approach to defending against a JavaScript attack might be to enclose 
comments around any JavaScript that can legitimately run. In this method, the legitimate 
client is already aware of the requirement to remove comments before the eval() method 
for the JavaScript to work. However, the beauty of this method is that the attacker has no 
way of knowing that this mechanism is in place. 


Framework Summary 

Prevents 
JavaScr, pt 
Hrjne Icing? 

Do jo Supports JSON Defaults to POST, but dots not 

explicitly proven t Java So rips Hijacking 

No 

DWR 1.L4 Uses art expanded versum of '/SON. Does not 

implement (Twr JawScripi Hijacking prevention 
mechanisms 

No 

DWR 2,0 Isos art expanded tm ion of JSON Uses double 

cookie submission to prevent XSRF and a thr&v 
statement in JavaScript responses to present 
JavaScript Hijacking 

les 

GOOgl? Web Toolkit Supports JSQ\ POST by default} AfffWW. 

documentation describes how So make GUT requests 
instead and does not mention unv security 
ramifications 

No 

j Query Supports ISON. Defaults to GET 

No 

Microsoft Alias Supports JSON. Uses POST by default, but allows 

programmers to easily change POST to GET arid 
encomaga dring softy performance and caching. 

No 

M&chiKif Supports JSON. Defaults to GET 

No 

\foo.fx Supports JSON. Defaults to POST, but can easily 

be configured to me GET 

No 

Prototype Supports JSON Defaults to POST when no method 

/v specified, bath emlty customfutblefor using 
either POST or GET 

No 

Scrtpt.ceulo.iis Supports JSON. Provider additional 11 controls 

and uses the Prototype library for generating 
requests. 

No 


Figure 48. A listing of popular Ajax frameworks and their ability to thwart JavaScript 
Hacking from [48]. Note DWR’s ability to thwart most XSRF attacks and JavaScript 

Hijacking attempts. 


Hopefully, this chapter has provided the reader with a baseline of concerns to 
address with any future Web 2.0 application, especially an Ajax one. The major points to 
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take home from a security angle are that with Ajax, a malicious attack need no longer 
utilize iframes and wait for user input. The paradigm shift with Web 2.0 is that 
asynchronous data can now flow back and forth and that of course includes malicious 
data. From a program management perspective, the security needs of the individual 
applications within the enterprise need to be closely evaluated and then and only then can 
a competent security strategy be laid out. As was previously stated, the “Golden Mean” 
is what is desirable, “knee jerk” security is hardly an optimal solution but it is obviously 
better than nothing at all. Extremes, in general, are bad, both in terms of Ajax Security 
and life. Additionally, Figure 48 shows the prospective program manager a table to 
evaluate how a potential Ajax framework might stand up to the more popular attacks “out 
of the box.” 

H. CONCLUSIONS 

As Google Gmail, MySpace.com, and now Apple have found Web 2.0 is a 
double-edged sword at times. With the increased amounts of JavaScript come increased 
amounts of vulnerability points in a perspective web application. Apple recently, patched 
the iPhone to disallow XSS attacks in their Safari browser that can let hackers dial out on 
compromised iPhones. The key takeaway of this chapter is application and defense of 
the Sandbox concept. The security schema of a web site cannot allow the Sandbox to be 
circumvented through direct execution of JavaScript code or predictable URL-naming 
schemas. The preceding can be accomplished via mechanisms which allow for indirect 
execution of JavaScript on the server-side by means only known to the developer such as 
encasing all JavaScript with comments, or placing infinite loops in the JavaScript code 
that are removed at run time by the server-side. To prevent XSRF attacks it is vital that 
the URL schema of a website be unpredictable by incorporating random values such as 
SessionIDs into the URLs. The security of the enterprise will always be of prime 
importance for the DoD, thankfully JavaScript has been around for years and as a child 
technology, Ajax inherits many of the lessons learned from that endeavor. The DoD has 
clearly been successful with integrating JavaScript into web-based applications and if 
they utilize the same policies while handling Ajax DoD will realize the same benefits and 
successes. 
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VI. AJAX DESIGN PATTERNS FOR WEB SERVICES 


A. INTRODUCTION 

The term design pattern is oftentimes a bit confusing to the novice reader but is 
really just an extension of a basic precept in computer science. The preceding is akin to 
not “reinventing the wheel.” Design patterns give the Ajax developer and project manger 
a lot of momentum going into a project by leveraging lessons-learned. The Naval 
Aviation community has a saying that the Naval Air Training and Operating Procedures 
Standardization (NATOPS), manual was written in blood. In a far less dramatic way 
Java design patterns for web services are written in the same fashion. Typically, a new 
design pattern for web services or web development in general is born from the project- 
related disasters of the past. 

By utilizing a combination of responsible design considering such things as 
usability, performance, and security and a coherent testing SOP (Standard Operating 
Procedure), a project will likely succeed. Christopher Alexander originated the idea of 
design patterns in 1977. 49 According to Alexander, the world’s set of architectural 
patterns across cultures can basically be summed up into 253 patterns such as “Market 
Full of Shops.” From the patterns, Alexander hypothesized that software engineering 
might leam a lesson and establish a set of best practices that were recognized as such by 
industry to prevent reinvention of the wheel. In this chapter, a thorough exploration of 
Ajax design patterns to expose web services such as REST (Representational State 
Transfer), RPC (Remote Procedure Call), and Ajax Stub. Various forms of messaging 
within the context of a web service will also be discussed such as HTML Messaging, and 
XML-Messaging, and the new JSON notation. The focus will be concerned with 
industry best practices regarding usability of design weighed against performance. 


49 Design pattern (computer science). (2007, June 5). In Wikipedia, The Free Encyclopedia. 
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B. OVERVIEW 


Given the fact that design patterns have been around since 1977, it is of no 
wonder that industry, in particular the open source Java enterprise solutions industry 
utilizes them to the n th degree. However, the project lead, or project manager must 
ensure that they do not put their total confidence in a single pattern. The preceding is 
particularly important in terms of scalability. A good case study for the preceding can be 
eBay itself, which was rewritten in 2000 for the Java Enterprise Edition (EE) platform. 
eBay does a few unconventional things in the name of scalability such as attempting to 
eliminate any and all session state 50 and moving it to the persistence layer, which is 
handled with a custom O/R (Object-Relational) Mapping solution (most likely a 
Hibernate derivative). The preceding is where eBay differs from a pure Java EE 
specification “by the book” implementation. A truly Java EE implementation typically 
leverages the application server and application layer to manage state, while eBay 
delegates state management to the persistence layer. 

The point, of the preceding is not to delve into the weeds of the details of modem 
day Java enterprise design decisions so much as to demonstrate that a pattern is merely a 
suggestion. eBay lives and breathes scalability, which is the reason they migrated in the 
first place as the upper limits of their Oracle databases were being taxed 51 . eBay 
achieved horizontal scaling by splitting up their databases and mapping them to 
individual use cases instead of entire business processes thereby avoiding entire 
workflows being fed into a few monolithic servers. 


C. RESTFUL DESIGN PATTERN 

When discussing Ajax web services RESTful architecture is a concept that comes 
about frequently in conversation. The goal of a RESTful architecture is to standardize 
web service development by mapping actions to HTTP 1.1 methods (GET, POST, PUT, 
DELETE) and resources to URLs. In the REST world, the server is seen as a big “blob” 
of resources and access to those resources are controlled using actions (operations), 
which map to respective HTTP methods. The RESTful architecture was the brainchild of 

50 Nuggets of Wisdom from eBay’s Architecture. (2004, June 21). 

51 Dan Pritchett and Randy Shoup. (2006, November 29). eBay Architecture. 
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a doctoral thesis by Roy Fielding 52 , who was also the main architect of HTTP vl.l. 
Figure 49 is a diagram of the basic concepts behind REST. 
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Figure 49. A diagram of RESTful architecture from [54]. 


From a project manager’s perspective, REST is a very clean API to interface an 
Ajax application with Web Services. In a way, REST promotes good practice by 
honoring it. In other words, if the industry leaders are using RESTful Web Services it 
will undoubtedly attract developers. Notable examples of the preceding include 
Amazon’s REST API, and eBay’s REST API 53 . Developers fuel technologies and the 
technology with the most developer support and momentum will win at the end of the 
day. REST is currently considered by many to be a cleaner design pattern than Remote 
Procedure Call (RPC). REST also conforms to the current industry belief that services be 
stateless, idempotent, and self-documenting. 

Within the REST world of web services design, there are two main principles: 
resources as URLs and operations as HTTP Methods. A resource URL can be thought of 
as a business entity, i.e., a noun. The key concept to grasp with regards to the resource 
URL is that each resource has a unique URL in the RESTful paradigm. By operations as 
HTTP Methods, the utilization of the basic HTTP Methods: GET, POST, PUT, and 
DELETE are meant. REST seeks to leverage the basic HTTP Methods and map each one 

52 Jim Standley. (2005). RESTful Architecture. 

53 eBay REST Developer Center. (2007). eBay. 
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to corresponding actions. In summary, nouns or “things” in the web service architecture 
are conveyed as resource URLs while verbs, i.e., “actions” are conveyed as operations on 
HTTP methods. The methods can most logically be mapped to SQL (Structured Query 
Language) commands. A GET is similar to a SQL SELECT, while a DELETE maps 
directly to a SQL DELETE. POST is similar to INSERT with an auto-generated 
(sequenced) ID. Finally, PUT is like INSERT or UPDATE IF EXISTS with a specified 
ID. It is important to realize that the browser oftentimes caches GET requests locally 
while other types of requests do not get the same treatment. The preceding are a few 
design considerations that must be considered and weighed as GET requests also have 
security issues involved with them as discussed in the Ajax security chapter. 

Google Accelerator had an incident with the exact same problem in 2005, in what 
is known as the Backpack-Accelerator Incident 54 . Google Accelerator is a proxy that 
prefetches links for the client. Backpack is a non-RESTful web service providing 
Calendar/Planner based services. In Mid 2005, Google Accelerator started to exhibit 
strange behavior in its interaction with numerous non-RESTful Services. The design 
flaw that Google Accelerator had was its assumption that all the web services that it 
interacted with were RESTful and it therefore intermittently clicked on any link. The 
way Backpack was designed, i.e., non-RESTfully; it frequently contained links (URLs), 
which deleted user data via GET calls so Google Accelerator was inadvertently deleting 
user data. 

The following are advantages that utilizing a RESTful architecture can bring: 

• RESTful Architecture supports the best practice that Web Services be 
stateless in that one of its main goals is to be able to switch clients at any 
time and obtain the same result. By doing so and being browser 
independent, the Web Service will be more scalable. As an important 
side-note, by stateless server-side only statelessness is intended here. 
RESTful Architecture imposes no restrictions on what the client-side 
chooses or chooses not to remember. 

• RESTful Architecture supports the best practice that Web Services be 
idempotent, that is if a message is sent from the client to the server the 
result needs to be the same if it is sent once or ten times. The paradigm of 
bounding all possible actions to the HTTP 1.1 paradigm of GET, PUT, 

54 Michael Mahemoff. (2006). Ajax Design Patterns. 
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POST, and DELETE helps to facilitate and encourage this practice within 
the community of Web Services that are RESTful. 

• RESTful Architecture supports the best practice that Web Services are 

self-documenting which entails that typically Base URLs describe 
themselves. Furthermore, any error handling or degradation must 
typically be verbose and as helpful as possible. A good self-documenting 
Web Service paradigm will also rely on web standards such as XML 
Schemas and Document Type Definition (DTD), which REST also does. 


Issues with REST architecture include the lack of a search functionality (action), 
which will inevitably lead to numerous customized “in-house” solutions. Furthermore, 
between browsers while GET and POST are fairly standardized, PUT and DELETE most 
definitely are not. Applications using the REST API pattern typically require more 
maintenance than their RPC counterparts as well. 


D. RPC DESIGN PATTERN 

RPC (Remote Procedure Call) is currently the main alternative to REST in terms 
of industry support for web service architecture. There are various forms of RPC, which 
include: XML-RPC, Simple Object Access Protocol (SOAP) and Ajax Stub. RPCs are 
generally characterized as actions with a verb like URL, i.e., 

http://www.foo.com/?command=startGame . A Popular application of the RPC concept is 
embedded in the APIs of popular websites such as Flickr and Kiko. Figure 50 is a high- 
level architecture of an RPC framework. 
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Figure 50. A notional RPC Service architecture from [54]. 
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1. XML-RPC Architecture 

XML-RPC is the simplest type of RPC call in that the client utilizes 
<methodCall> and <methodName> tags which are exposed on the sever side as methods. 
The client uploads an XML document that uses the aforementioned tags and the server 
side returns the response, again as XML. SOAP is very similar to XML-RPC except it 
extends the functionality of XML-RPC to include the ability to use custom data types and 
asynchronous messaging. SOAP is intended to automate the translation of SOAP calls to 
whatever the calling language is. From the preceding things such as Enterprise Java 
Beans (EJBs) can be exposed as web services. SOAP is considered to be too obtuse and 
bloated for its own good by many developers and is controversial. 

2. Ajax Stub Architecture 

This architecture seeks to automate the invocation of Web Services on the client 
side by using JavaScript wrappers. Ajax Stub is more of an all-in-one solution to Web 
Services than REST or XML-RPC in that while the preceding architectures will create 
Web Services the developer still needs to invoke them on the client. In fact, the 
Remoting is so abstracted away from the developer in this architecture that calls to 
XMLHttpRequest or even its wrapper are also abstracted. The result is a framework that 
is clear to the developer but may be a bit obfuscated under the hood. The preceding 
might be a concern if many third party clients are interested in an Ajax-based Web 
Service and wanted to use aspects of it. In the aforementioned scenario, obviously Ajax 
Stub might pose problems if the framework used included developers who were lax on 
documentation or comments. In ten words or less, Ajax Stub is nice but, at the project 
management level, cognizant loss of control must be realized. Below is a high-level 
diagram of a basic Ajax Stub architecture; note the extra layer of abstraction at the client 
to make remoting transparent. 
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Figure 51. An Ajax Stub architecture from [54]. 


E. HTML-MESSAGE DESIGN PATTERN 

HTML Message architecture sends HTML snippets to the client side, which adds 
them to the DOM via an innerHTML call. However, HTML Message architecture needs 
to be used sparingly because it couples services with display. The preceding makes 
parallel development sometimes difficult. The reason to use the HTML-Message driven 
pattern is generally when applying Ajax to legacy applications since HTML generation is 
normally a part of the legacy application anyway. Also, HTML Message architecture is 
generally good with perfonnance and is also a good option if graceful degradation is a 
key concern since most of the logic will reside on the server-side. Popular examples of 
HTML Messaging include Digg Spy (Ajax-enabled dynamic news), http://digg.com/spv 
and Rapha (Ajax Shopping Cart) http://www.rapha.ee . Figure 52 shows a high-level 
architecture of a typical HTML-Message architecture. 
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Figure 52. An HTML Message architecture from [54]. 


F. XML MESSAGE ARCHITECTURE 

In the past, communication between the server-side and the browser was done 
with basic text messages. The architecture for the preceding might normally involve a 
customized set of business logic at the application layer to parse what was normally a 
very business-specific format. With XML, the headache has been remedied and, for 
some time now, industry best practice has been to send messages back and forth using 
XML. There are two major questions that the developer must answer after XML is 
chosen as the data interchange format of choice. The first is to simply decide how the 
server-side will produce the XML. The second is simply how the browser will convert 
the XML. While the learning curve for the XML message architecture can be quite steep 
at times, especially when learning to master XSLT it is clearly industry best practice and 
has spawned such huge successes as Google Maps and Netflix and Protopage 55 . 

1. Decide How Server Will Send XML 

• Custom code to create XML string 

• Build DOM object then serialize 

• Use framework to convert data structures to XML 

• Must decide on using schema or DTD 

2. Decide How Browser Will Handle XML From Server-Side 

• Manual JavaScript conversion 

• Use XSLT (eBay uses this) to convert the XML to HTML 


55 Protopage Home. (2007). Protopage. 
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Figure 53. Plain Text Message architecture from [54]. Housingmaps.com is a great real- 
world example of how this architecture can create useful mashups. 



Figure 54. XML Message architecture from [54]. Netflix’s Top 100 is a good example 

of this architecture. 


Figure 56 is a screenshot of Netflix and their Top 100 56 page. Note that the user is easily 
able to hover the mouse over any title and instantly bring up associated information and 
the average user rating for the respective film. Utilizing an XMLHttpRequest call does 
the preceding and the movie data comes in from the server-side as XML and gets 
converted to HTML. Figure 55 shows the reader a basic structure of what the movie data 
looks like in raw XML fonn coming from the server. 


<MOVIES> 

<MOVIE ID="60031236" POS="17" DS="0"> 

<TITLE>Kill Bill: Vol. 2</TITLE> 

<SYNOPSIS>In this film noir tale written ... </SYNOPSIS> 

<DETAILS RATED="R" RELYEAR="2003" GENREID="296" GENRENAME="Action &&& 
Adventure"/> 


56 Netflix’s Top 100 Home. 
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<STARRING> 

<PERSON ID="92495" NAME="Uma Thurman"/> 

<PERSON ID="20008295" NAME="Lucy Liu"/> 

</STARRING> 

<DIRECTOR> 

<PERSON ID="20001496" NAME="Quentin Tarantino"/> 

</DIRECTOR> 

</MOVIE> 

</MOVIES> 

Figure 55. XML movie data on Netflix before conversion into HTML from [54]. 



Figure 56. Screenshot of Netflix Top 100 popup functionality from [56]. The figure 
demonstrates a real-world application of XML Message architecture in action. 


76 







































Figure 57. An example of an Ajax portal from [55]. The Protopage Homepage is also an 
example of XML Message architecture. Google Maps is probably the most famous 
examples of XML Message architecture. Information is downloaded in XML and 
converted into HTML via XSLT on the client-side. 

G. JSON MESSAGE ARCHITECTURE 

When passing data between the server-side and the client, at times, a lighter, 
cleaner implementation is desired. JavaScript Object Notation (JSON) is meant to fill the 
preceding gap. JSON is a language neutral serialization format that allows for objects to 
be sent over the wire whether they are written in C++ or Java or any language. JSON is 
perfectly suited for passing parameters from the server-side to client-side because for all 
intensive purposes it is JavaScript and is used in such practical applications as Kiko 
Calendar 57 and Yahoo Mindset. 58 


57 Kiko Calendar Home. (2007). Kiko. 

58 Yahoo Mindset Home (2007). Yahoo. 
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1. JSON Advantages 

• JSON is more compact than XML 

• JSON typically faster to parse in browser 

• JSON is a concrete data format no design decisions need be made 
like with XML 

• JSON slightly more supported in the browser since it is JavaScript 
after all 

• JSON Compatible with YAML (Yet Another Markup Language) a 
lighter-weight version of XML 

Figure 58. The potential advantages of using JSON as an intermediate data fonnat from 

[54]. 


2. JSON Disadvantages 

• XML scales better than JSON 

• XML more familiar to more people within the IT community 

• Better libraries and tool support, XPath, XSLT Translators, i.e., 
Altova XML Spy 

• While not a concrete format for data the extensible nature means 
XML has the power to choose one of several implementations 

Figure 59. The potential disadvantages of using JSON as an intermediate data format 

from [54]. 



Figure 60. JSON Message Architecture from [54]. JSON was created in 2002 and is 
sometimes a cleaner alternative to XML. JSON is generally faster to parse but XML 
scales better. XML is also more well known and is more self-documenting that JSON. 
Examples of JSON in practice include KIKO Calendar, an Ajax web scheduling 

application. 
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Figure 61. An example of Submission Throttling from [54]. 
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Figure 62. An example of Cross Domain architecture from [54]. 
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Figure 63. Yahoo Mindset screenshot from [58]. Note the usage of a slider to influence 
search results based on whether the search is shopping or a research based search. Again, 
Web 2.0 is getting the world closer to a truly semantic web. 


H. CONCLUSIONS 

As seen with Google Maps, Amazon, eBay, and Nasa World Wind the ability to 
expose a set of well-designed APIs to the public will exponentially increase the amount 
of traffic and popularity of a web site while at the same time providing rich-value to the 
customer. The preceding situation is a win-win in that the customer gets an interface to 
useful web services for their own personal applications while the service provider gains 
that much more influence within industry by serving as an intermediary for 3 ld party web 
applications, i.e., Web 2.0 mashups. The entire idea of a mashup such as 
Housingmaps.com really started with Google Maps. Google Maps is certainly a 
disruptive technology and is certainly a flagship example of the potential of applying 
good design principles such as the using the appropriate amount of Ajax and the usage of 
XSLT on the client. By utilizing similar principles, X3D-Earth can leverage Ajax, 
Ajax3D and web services to not only create a server-side geospatial web application, but 
also expose a rich set of APIs for the DoD and industry alike to use. 
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VII. AJAX3D 


Figure 64. 



Ajax3D Logo from [59]. Ajax3D is a way of modifying the 3D scene graph 
dynamically by using asynchronous server-side methods. 


A. INTRODUCTION 

The Ajax3D 59 concept was created by Tony Parisi (of VRML fame) in August, 
2006. Basically, Ajax3D is simply applying Ajax techniques such as manipulating the 
DOM on both server and client side, but on a 3D scale. More specifically Ajax3D is 
dynamically manipulating the X3D scene graph, through the ISO SAI (Scene Access 
Interface), on the client-side through calls to XMLHttpRequest. The SAI component has 
a similar construct called createX3DfromURL. 60 Through the usage of Ajax3D, and a 
few new X3D nodes custom-tailored for the X3D-Earth Project an X3D geospatial 
system is completely viable. 


B. OVERVIEW 

The world of X3D browser plug-ins closely mirrors that of the real world 
“Browser Wars” that occur between rival organizations such as the one between Mozilla 
and Firefox and Internet Explorer. With regards to 3D Browsers currently not all support 
the SAI, but what is important to note is that all are moving towards supporting the SAI. 
Currently, only Flux and Xj3D support the usage of tying Java into X3D nodes by 
utilizing SAI. 3D browsers also suffer from the lack of a real industry de-facto standard. 
While certainly Flux and Xj3D have been out for years, there is no dominant browser to 
build one big user base from, with the helpful forums and developer groups that follow as 
a result. However, some of the other browsers such as Octaga have shown great potential 
for growth owing to their minimalist yet intuitive user interface. Currently, the 

59 Ajax3D Project Home. (2007). 

60 Tony Parisi. Ajax3D: The Open Platform For Rich 3D Web Applications. 
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bottleneck of development with regards to a server-side X3D-Earth lies with the X3D 
browsers. As was previously mentioned, there is really no strong industry force to 
standardize the X3D browser and as such they are all feature-different. Once the browser 
technology matures on the X3D side of things, and each vendor possesses a working 
implementation of Geospatial Nodes, then the concept of X3D-Earth on the server-side 
can migrate from theory to reality. 

C. X3D SCENE ACCESS INTERFACE (SAI) 

It is important to realize that the X3D equivalent to the DOM is the SAI. Through 
the X3D SAI, Ajax3D will apply XMLHttpRequest in a similar way to how it is applied 
in the usual sense of a 2D three-tiered web application. The preceding will work as long 
as the 3D Browser in question is SAI-Compliant. Figure 65 is a screenshot of the current 
X3D SAI architecture 61 . 
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Figure 65. The ISO SAI Architecture from [61]. 


61 Len Bullard. (2007, April 25). AJAXing the X3D Sequencer: ISO SAI Architecture. 
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D. AJAX3D HELLO WORLD EXAMPLE 

In this first example, a simple “Hello World” application 62 will be built utilizing 
X3D and Ajax techniques. The final result is shown in the Figure 66. 
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Figure 66. An example of a dynamic Hello World with the help of Ajax and X3D from 

[62]. 


The first step in integrating Ajax3D into a static web page is to use the HTML 
EMBED or OBJECT tag. The tag is displayed in Figure 67. 

<embed width="640" height="480" name="FLUX" src=''helloajax3d.x3d" 
type="model/x3d" dashboard="0" bgcolor="OxFFFFFF"> 

Figure 67. An example of an EMBED tag referencing X3D within presentation layer 

from [62]. 


62 Tony Parisi. (2006, October 12). Ajax3D Hello World Example. 
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<?xml version="1.0" encoding="UTF-8"?> 

<!DOCTYPE X3D PUBLIC "ISO//Web3D//DTD X3D 3.0//EN" 

"http://www.web3d.org/specifications/x3d-3.0.dtd"> 

<X3D profile='Immersive' > 

<head> 

</head> 

<Scene> 

<NavigationInfo type='"EXAMINE"'/> 

CTransform translation='-3 2 0'> 

<Shape> 

<Text DEF="DynamicText" string='""'> 

<FontStyle size='2' family='sans'/> 

</Text> 

<Appearance> 

<Material diffuseColor='0 0 O' emissiveColor='.2 .33 

l'/> 

</Appearance> 

</Shape> 

</Transform> 

</Scene> 

</X3D> 


Figure 68. X3D Source Code for Hello World Example from [62]. Note no text values 

exist yet. 


Once the X3D has been successfully embedded, browser DOM manipulations can access 
the X3D Scene Graph with a few more lines of code. The following JavaScript code 
assigns a Flux object to the browser DOM and then grabs a handle to the X3D by calling 
the getExecutionContextQ method on the browser object. 


var context = browser.getExecutionContext() ; 

Figure 69. An example of obtaining handle to X3D scene graph using ISO SAI from 

[62]. 

Once the handle to the X3D Object has been established, the Ajax3D developer must 
then call methods which traverse the X3D scene graph. 


var theText = content.getNode("DynamicText"); 
or 

var nodes = content.getRootNodes(); 

Figure 70. An example of accessing individual nodes in X3D using the ISO SAI from 

[62], 
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Within the SAI, dynamic behaviors are defined via two methods: Events and 
Listeners. In the SAI, an event is either a settable field or a field that fires a callback to 
the SAI when its contents change. The SAI also has a Listener construct which are 
objects that have callback methods that are invoked when an event is generated. Ligure 
71 shows a TouchSensor, which responds to user mouse clicks. 


var observer = new Object; 

observer.readableFieldChanged = clickCallBack; 
sensort.touchTime.addFieldEventListener(observer); 

Ligure 71. A TouchSensor call within the Ajax3D script from [62]. 


Next is the fun part of the tutorial and the real meat of dynamic X3D, which is the 
actual dynamic generation of 3D content. The SAI supports dynamic X3D through input 
as strings or URLs. The following code is an example of creating X3D dynamically from 
a string: 


var BoxShapeString = "<Shape><Box size = '.5 .5 .1'/><Shape>"; 
var newscene = Browser.createX3DfromString(BoxShapeString); 

Ligure 72. An example of Dynamic X3D scene creation using the ISO SAI from [62]. 

E. AJAX3D DYNAMIC SCENE CREATION EXAMPLE 

One of best ways to visualize Ajax3D is by step-by-step example. The following 
tutorial will introduce the reader to basic Ajax3D Dynamic Scene Creation 63 . The first 
step is to download the file named ajax3d-dynamic.zip from: 

http://www.aiax3d.org/content/t3/indexa.html . 

The tutorial is completed in two steps. The first step is to load the dynamic 
content using XMLHttpRequest. The second step is to dynamically create a 3D Object 
and add it to the scene. The tutorial does need an additional setup step which entails 
creating an EMBED tag within the html page to associate any X3D content with the Llux 
browser. The preceding setup is shown in Ligure 73. 


63 Tony Parisi. (2006, October 12). Ajax3D Dynamic Scene Creation. 
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<embed width="640" height="480" name="FLUX" src=" " type="model/x3d" 
dashboard="0" bgcolor="OxFFFFFF"> 


'igure 73. An EMBED tag pointer to associate X3D content with the Flux Browser from 

[63]. 


Traditional server-side Ajax techniques differ slightly from Ajax3D in that many 
of the traditional Ajax frameworks handle JavaScript automatically for the development 
team. Typically, the JavaScript is generated on the fly through a “JavaScript Engine” 
which is basically a library of jars that contain the java code needed to keep the developer 
programming in java. Unfortunately, at this time no such libraries (Java Engines) exist 
for Ajax3D. Therefore, the next step lays out modifications to a few JavaScript files, 
which will later be referenced in the presentation layer. 

Step 1: Load the Dynamic Content using XMLHttpRequest (edit tutorial.js) 

In this step, tutorial.js is the primary driver of this action. The major parts of the 
tutorial.js are included below for reader convenience. Note that this example is 
dependant on Flux as the 3D browser plug-in and Microsoft Windows running on the 
client machine. 


// in the body of onClick: 
str = sendRequest(request); 

// Helper function to create request 
function createXMLHttpRequest() 

{ 

try { return new ActiveXObject("Msxml2.XMLHTTP"); } catch (e) {} 

try { return new ActiveXObject("Microsoft.XMLHTTP"); } catch (e) 

{ } 

try { return new XMLHttpRequest (); } catch(e) {} 

alert("XMLHttpRequest not supported"); 
return null; 

} 

// Helper function to perform request; synchronous to keep it simple 
for now 

function sendRequest(url) 

{ 

var xmlhttp = createXMLHttpRequest () ; 

if (xmlhttp) 

{ 

var i; 

xmlhttp.open("GET" , url, false); 
xmlhttp.send("") ; 
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// now extract the views based on the response, repopulate 
array, list, and form items 

return xmlhttp.responseText; 


} 


Figure 74. TutoriaB.js Code Snippet showing XMLHttpRequest Object from [63]. 


In the JavaScript code, function createXMLHttpRequest() creates two types of 
objects either IE compliant or Firefox compliant for a more cross-browser compatible 
application. However, the Flux-dependency on the Windows platform is still a problem. 
The sendRequest() function utilizes the XMLHttpRequest object to do the send request. 
The send request can be called either synchronously or asynchronously, which is a key 
point to remember. In this example, send is called synchronously but if one wished an 
asynchronous call can be achieved by a callback function passed as an argument to 
send(). 

Step 2: Dynamically create a 3D object and add it to the scene (edit ajax3d.js) 

After obtaining the X3D data dynamically to interact with the scene graph, the 
developer must now call the correct node by utilizing the SAI. The major parts of the 
ajax3d.js file are included in Figure 75 for reader convenience. 

function createX3DFromString(str) 

{ 

var scene = browser.createX3DFromString(str); 
var rootnodes = scene.getRootNodes(); 
var i; 

// Do a bit of work to deal with the quirky X3D add/remove root 
node paradigm 

for (i = 0; i < rootnodes.length; i++) 

{ 

node = rootnodes[i]; 

scene.removeRootNode(node) ; 

context.addRootNode(node) ; 

} 

} _ 

Figure 75. The ajax3d.js code snippet showing X3D node retrieval from [63]. 


In the code, the createX3DfromString method simplifies node retrieval into one 
composite function than can be called multiple times. The code traverses through the 
array of returned nodes, removes them, and then adds them to the live object. Once the 
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code is working, Figure 76 shows how the screen appears in the client web browser after 
loading index.html, assuming that Flux or a compatible browser is already installed as a 
plug-in. 


Tutorial 3 : Dynamically Generating a Scene 



Figure 76. Initial Screen of Ajax3D tutorial after correctly loading index.html but before 
pressing any buttons for geometry from [63]. Note a black screen can be seen at this 

point, as no user input has occurred. 
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Tutorial 3 : Dynamically Generating a Scene 



Figure 77. X3D scene in Flux browser after pressing cube, cone and sphere buttons 

respectively from [63]. 


F. CONCLUSIONS 

From the preceding code examples, hopefully, the reader can see the potential 
benefit that Ajax3D can provide to the X3D-Earth initiative. Ajax3D allows for the 
XMLHttpRequest object to provide the service member with dynamic XML-based 
content based on input from web controls or traditional X3D constructs such as 
eventListeners or touchSensors. However, X3D-Earth still needs the ability to quickly 
and automatically add overlays to any terrain that is auto-generated by Rez. The 
preceding might either arise from the development of new nodes based on the Proto Node 
specification or can arise from an agreement from within the X3D community to 
standardize entirely new nodes meant to facilitate the design of X3D terrain overlays. 
Such an effort can be best served if KML were kept in mind during any potential 
speculation of node addition due to the fact that it is a de-facto industry standard. 

By doing this, X3D-Earth can provide layering information that can dynamically 
change as the user zooms in/out of the terrain. However, instead of using a client-side 
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application and OpenGL to do the rendering, the X3D-Earth client can do the same by 
utilizing any standard web browser with an X3D plug-in. The need for asynchronous 
data flow is critical, in this case, because of the dynamic nature of viewing terrain data. 

In such applications, users frequently wish to change their viewing window by zooming 
in and out and changing the rotation and orientations as well. From a usability standpoint 
alone, Ajax3D is critical to the success of the preceding. Imagine having to reload the 
scene graph with every zoom operation within X3D-Earth. Google Maps is a web-based 
Ajax application that manages to avoid page refreshes upon zooming or dragging events. 
X3D-Earth can do the same by leveraging Ajax3D on the server-side, which holds much, 
more potential for forward deployed forces and can be an idea that is just as 
revolutionary. 
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VIII. INTEGRATING X3D-EARTH WITH KML AND COLLADA 


A. INTRODUCTION 

With regards to the X3D-Earth initiative, one huge area of concern is the ability to 
add layering functionality in the future to terrain sets. By layering, roads, zip code data, 
landmarks, 3D Buildings is inferred. The preceding problem set has already been 
semantically defined in what is known as Keyhole Markup Language (KML), an XML 
markup language for describing terrain. KML was created by the Keyhole Corporation, 
which was acquired by Google in 2004. The Keyhole tenninology, in the definition is 
not random; it is in reference to the old Cold War Era “KH” spy satellites 64 . Since 2004, 
the KML format has been integrated into a zipped format called KMZ. Furthermore, 
since 2006, a new interchange technology called Collaborative Design Activity (Collada) 
has emerged as an industry standard for textured 3D buildings within terrain systems. By 
utilizing KML, KMZ, and Collada, for 3D overlays and buildings, huge strides can be 
realized within the X3D-Earth Project and the concept of a viable terrain system based on 
X3D can be bom. 

B. OVERVIEW 

In order for the X3D-Earth project to really add any value to the DoD, overlays 
need to be embedded on top of the terrain. For instance, an overlay of a Predator UAV 
track might be desired, or an Ajax Panel containing icons representing armored divisions 
might be implemented so commanders on the ground can do planning at the theater level 
through Ajax-supported drag-and-drop (see Figure 33 for ICEfaces drag-and-drop 
exemplar) into an X3D window. Picasso is quoted as saying, “Good artists copy, great 
artists steal,” such is the case with how X3D-Earth can approach Google and their KML 
2.1 specification. Again, there is no need to reinvent the wheel and create a custom X3D- 
Earth terrain overlay markup language. KML is also currently up for standardization 
with the Open Geospatial Consortium (OGC) 65 , http://www.opengeospatial.org, as a 


64 Keyhole Markup Language. (2007, September 4). In Wikipedia, The Free Encyclopedia. 

65 KML Open Geospatial Consortium, OGC Best Practice 2.1.0. 
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standard way to perform the business of terrain overlays and is already considered a de- 
facto best practice, according to the OGC. 


C. X3D-EARTH 

The X3D-Earth project was started as a follow on effort from the Web 3D Open 
Geospatial Working Group. Associate Professor Don Brutzman and Mike McCann of 
the Monterey Bay Research Institute head the X3D-Earth Working Group. X3D-Earth 
has several goals 66 all of which are necessary for DoD to leverage 3D geospatial data on 
the web but not get locked-in to a specific vendor while doing so. 

• Build a backdrop X3D model of planet Earth 

• Use publicly and privately available terrain datasets 

• Use publicly and privately available imagery and cartography 

• X3D technologies will be applied to maximize interoperability among 
spatially aware implementations 

• Provide linkable locations for any place 

• Provide hooks for physical models 

• Use open standards, extensions and process 

• Define functionality in a platform-independent manner 

Figure 78. A listing of the established goals of the X3D-Earth Working Group from [66]. 

Currently, the X3D-Earth Working Group has been enormously successful in 
establishing an underlying foundation for a potential server-side solution to X3D-Earth. 
Through the promotion and utilization of open source standards the group has an 
established 3D model archive called Savage Model Archive, which contains military 
models of interest for use in 3D visualizations. While the Savage Model Archive does 
not have the breadth of models as a system like Google 3D Warehouse, it provides 
valuable exemplars for how meta-data needs to be handled which give 3D models 
platform specific behaviors at runtime. One of the major criticisms of Google 3D 
Warehouse is that its libraries contain models with inadequate or non-existent meta-data. 


66 X3D-Earth Home Page. (2007). Web3D Consortium. 
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Furthermore, the working group has been successful at establishing partnerships 
with industry such as Sun and Nasa to further develop open solutions and standards for 
the DoD. Recently, the X3D-Earth Working Group acquired terabytes of storage by 
purchasing Sun Storage Area Network (SAN), servers for an eventual implementation of 
the geospatial system to be feasible. As a point of reference, Nasa World Wind is 
approximately a 4.6-terabyte 67 geospatial system. 



Figure 79. Rez-generated model of Panama City Florida integrated into MOVES Savage 
Studio tool from [68]. The integration of Rez-generated models into Savage Studio now 
allows DoD Modeling and Simulation to run discrete-event simulations over more 
detailed terrain spaces than was previously possible. 


Recently, with the help of a series of working group members, Rez-generated 
models of San Diego, Panama City, Baltimore Harbor, San Clemente Island, and Oakland 
Harbor have been auto-generated 68 and integrated into the Savage Studio tool. Figure 79, 

shows an example of a Rez-generated model of Panama City from within the Savage 

67 NASA World Wind. (2007, September 7). 

68 Byounghynn Yoo. (2007, July 6). Multi-resolution Representation of Geospatial Information. 
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Studio tool. Savage Studio is a Java Application designed by the Scene Authoring and 
Visualization for Advanced Graphical Environments (SAVAGE), working group at the 
Modeling Virtual Environments and Simulation Institute (MOVES), to provide real-time 
discrete event simulations over 3D terrain. Currently, the X3D-Earth Working Group is 
working on attempting to standardize the Geospatial node specification across X3D 
browser implementations such as Flux and Xj3D. At the same time, the working group is 
also involved with alpha testing current Geospatial Node output in Rez to ensure that 
both the tiling mechanism and browser implementations are correct before moving 
forward with an actual implementation of an X3D-based geospatial system. 

D. X3D-GEOSPATIAL NODE OVERVIEW 

If X3D-Earth is ever to become a reality it is critical that the key players in the 
working group agree on implementation of a standard geospatial node. Currently, the 
specification 69 is being closely scrutinized with the intent of ensuring modern-day 
relevance by removing any unnecessary element references and adding references that 
may make sense in today’s more defined and mature geospatial system marketplace. 
While the current specification is certainly capable of providing a geo-referenced X3D 
scene, the working group must decide on whether or not the specification has all the 
elements needed to drive a modern day geospatial system. Currently, Rez, Flux, and 
Xj3D support the X3D geospatial node in theory. However, within the X3D-Earth 
working group alpha testing is currently being conducted to eliminate some of the bugs in 
practice. Figure 80 shows an outline of the current set of tags for an X3D geospatial 
node. 

The specification supports either geodetic or geocentric reference frames. A 
geodetic reference frame is the common elliptical earth model that is derived from a 
latitude-longitude centric view of the earth. A geocentric reference frame supports 
projection of the aforementioned ellipsoid on to a simple surface like a cylinder. The 
specification currently supports 23 earth ellipsoid models including the popular World 
Geodetic System 84 (WGS84). 70 

69 X3D Geospatial Node Specification, Web3D Consortium. 

70 World Geodetic System. (2007, August 9). In Wikipedia, The Free Encyclopedia. 
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By default, X3D utilizes single precision floating point values to reference all 
geometry, which is normally fine for most standard resolution displays under 1600 x 
1280 since sub-pixel noise can lose any precision gains. However, with geospatial nodes 
a unique requirement comes into play in that single precision numbers are insufficient. A 
single precision float has 23 bits of mantissa, which means that a coordinate can be 
accurate to one part per 8,388,607 or 2” . In a typical WGS84 ellipsoid, the equatorial 
radius is 6,378,137 m. By dividing the equatorial radius of the WGS84 ellipsoid by the 
8,388,607 a dividend of 0.8 is reached. In this case, 0.8 m is the maximum amount of 
geospatial precision that a single precision floating point can provide in a geospatial 
system. While certainly, not bad the precision can be improved. Therefore, the X3D 
Geospatial specification includes a construct called GeoOrigin, which allows for high 
precision coordinates using double precision floats. 


3D Geospatial Node 


X^D 



GeoCoordinate 

GeoElevationGrid 

GeoLocation 

GeoLOD 

GeoMetadata 

GeoOrigin 

GeoPositionlnterpolator 

GeoProximitySensor * 

GeoTouchSensor 

Geo Viewpoint 


'igure 80. The X3D Geospatial Node specification from [69]. Above is a table of URLs 
containing references to the specific components, which define an X3D Geospatial Node. 

Note that as per the specification there are two levels of Geospatial Node compliance, 
levels one and two respectively. Current, 3D browsers only support level one which does 

not include a GeoProximitySensor. 


The geospatial domain is unique in that velocity needs to be scaled to be realistic. 
For example, at sea level a speed of 100 meter per second may be perfectly acceptable 
but at altitudes in the upper atmosphere 100 meters per second is relatively slow for 
navigation purposes. In the specification the GeoViewPoint node handles the preceding 
problem space for the developer. 
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Currently, the X3D Geospatial Node specification for GeoProximitySensor is not 
supported by any of the current family of 3D browsers. The preceding is definitely an 
issue which needs to be resolved if any geospatial system is to developed. GeoProximity 
Sensor basically issues events to listeners, which respond to the user either navigating 
into or out of a bounding box, or rectangular space in 3D. Such a construct can be vital 
to allowing the lazy loading of tiles to take place on the client-side. If 
GeoProximitySensor were currently supported by the major 3D browsers there is no 
reason why Web 2.0 technologies like Ajax or most-likely Comet, in this case, might not 
provide reliable and asynchronous server-side data to the client without having to reload 
the entire scene graph. 

E. KML SPECIFICATION OVERVIEW 

KML 71 is currently used by Google Earth, Google Maps, and Nasa World Wind 
to describe and add value to their terrain data. The class tree for KML 2.1 is shown 
below. Note that as of May 31, 2007 a beta version of KML 2.2 has been released. The 
2.1 version of the KML class tree is shown here instead due to the fact that the current 
beta version of the KML 2.2 specification is a living document and subject to change. 


71 KML 2.1 API Reference. (2007). Google. 
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Figure 81. A class tree diagram of the KML 2.1 specification from [71]. 


F. KML IN GOOGLE MAPS 

Note that in the KML Specification, such things as BalloonStyle and LabelStyle 
are defined. The “balloon” is one of the most obvious and recognizable aspects of the 
Google Maps 72 application. A typical “balloon” is used as a way to place mark a location 
within the map area. Below is a screenshot of a set of “balloons” within the Google 
Maps application. Also take note of the LookAt element, which adds the ability to 


72 Google Maps. (2007). Google. 


97 






































determine the orientation of the scene with which to define the terrain system. 



Figure 82. Balloon KML element at work within Google Maps from [72]. 


Figure 83 is a screenshot of a basic KML file, which describes a basic scene within 
Google Earth 73 consisting of a simple Place mark tag and a tag for latitude and longitude 
(defined by a coordinates tag). The specification also allows for a simple scene 
description. 


<?xtnl vcrsion-"l.0" encoding-"(JTF-8"?> 

•OodI xmln3-”http://eorth.google,com/tool/2. 1”> 

<P iaceraar >c> 

<narne>Simple placemsrfc</name> 

<description>Attached co the ground. Intelligently places itseir 
at the height ol the underlying terrain.</description> 

<Point> 

<coordinates>-122.082203S42S683,37.122289901402SI,0</coord mateo> 
</Pomt> 

</Placen>ark> 

</kmi> 


Figure 83. A basic KML file showing place mark coordinate and description tags from 

[71]. 


Figure 84 is a screenshot of the result of double-clicking on the KML file 
(loading) from Windows Explorer. The KML file operates like any other media file and 
is li nk ed to Google Earth instead of the typical media application such as Windows 
Media Player or QuickTime. 


73 Google Earth. (2007). Google. 
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Figure 84. The identical KML Simple Placemark defined in Figure 83 from [73]. Note 
that the Simple Placemark is loaded from the Google Earth client-application at runtime. 



Figure 85. This is city level view of a Simple Placemark from [73]. Note that the KML 
layer provides city limits boundary data as well as city naming data. Demographics, 
crime statistics and much more can also be added as well. This is where the power of 

KML really shows itself. 
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Figure 86. This is the same Simple Placemark from [73]. Note that this figure shows the 
Google Campus at the highest level of resolution in Google Earth (Street Level) showing 
its location right in front of the Google Campus in Mountain View, California. Note the 
3D Buildings layer and the building texturing that comes included as a feature of Google 
Earth 4 through the adoption of Collada for 3D buildings. 

G. EASY 3D BUILDING OVERLAYS WITH COLLADA AND KMZ 

KMZ technology is nothing more than zipped KML with all necessary textures 
included. In fact, users frequently open up the KMZ file to explore its contents with 
WinZip, or any other decompression after renaming the extension to .zip. Since the 
announcement of Google Earth 4 in January of 2007, Google has introduced support for 
Collada technology into their KMZ files. The arrival of Google Earth 4 and the need for 
textured 3D buildings is also the primary driver behind the KMZ format as it is a more 
convenient way of encapsulating many textures with the KML that arranges and geo¬ 
positions them. What this means is that in every KMZ zip file not only has the necessary 
KML file included (always doc.kml for the KMZ format constrained by the specification) 
along with the necessary textures; but a Collada directory structure is included as well. 
The preceding entails including the main Collada .dae file in the model sub-directory and 
associated textures in the images sub-directory are also now packaged in Google Earth 
distributed KMZ files. 
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H. COLLADA AS A 3D INTERCHANGE FORMAT 

Collada technology came about from industry desire for a compatible 3D 
interchange format for 3D modelers which can work in harmony with all the major 3D 
modeling tools such as Maya, 3D Studio Max, and XSI. In the past, 3D Model fonnat 
has been a major sticking point and point of frustration for modelers in that there have 
been no well-received standardization efforts within the community. In 2006, adopting 
an XML based approach Collada was bom. Collada is part of a larger Industry 
Consortium called The Khronos Group, which seeks to standardize a variety of 3D 
technology in general. From a terrain system perspective, Collada is the tool that X3D- 
Earth might need to utilize in order to realize a textured 3D Buildings Layer. 

By utilizing Collada, Google Earth 4 was able to add drag and drop functionality 
to their terrain system. What this means is that a 3D Modeler can develop a building 
Model in Maya, 3DS Max, or any modeling tool and, after saving the file in Collada 
format (.dae) they can literally drag and drop the .dae file into a Google Earth window 
and have the new building display. The Khronos Group founded in 2000, by such 
industry leaders as 3D Labs, Intel, ATI, NVIDIA, Sun, and SGI, currently maintains the 
Collada Specification. The goal of the Khronos Group is to better facilitate standards 
within the realm of open source 3D platforms. Support from industry, for the Collada 
specification, has been strong and typically comes in the fonn of plug-ins. Maya, 3DS 
Max, XSI, and Adobe Photoshop CS3 are currently a few of the high profile names that 
are already on board. By utilizing Collada, Navy modeling and simulation can augment 
current capabilities of drag and drop, such as those that currently exist with Savage 
Studio. By doing this, and cleaning up the implementation while at the same time 
aligning themselves with industry standards Navy modeling and simulation will be 
setting themselves up for future success. 

I. INTEGRATING COLLADA AND X3D 

From the significant amount of industry momentum behind Collada such as Sun, 
nVidia, and SGI it may seem that Collada and X3D are destined to clash, as they are both 
XML-based means for describing 3D content. In a recent whitepaper entitled Developing 
Web Applications With X3D and Collada, X3D author Tony Parisi collaborates with 
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Collada creator Dr. Remi Amaud of Sony Entertainment in answering the question of 
how to potentially integrate the two technologies 74 . In the paper Parisi and Arnaud, 
argue that while a few people in the 3D community think that Collada and X3D cannot 
exist, the two formats were in reality meant to complement each other. The new Collada 
format is specifically geared for Digital Content Creation or (DCC) such as moving high 
polygon-count models between different 3D authoring tools like AutoDesk and Maya. 
From that point, Parisi argues that a future X3D will more easily be able to accept 
Collada without the need for any fancy conversion tools or external plug-ins and argues 
that while X3D is a delivery format, Collada is an interchange format. X3D is a 
visualization tool whereas Collada is mainly a content to promote DCC and rich content 
much like it is already used to provide rich content to the gaming industry. Figure 87 
provides a comparison of the domains covered by both Collada and X3D. 



Figure 87. A comparison of the domains of Collada and X3D from [74]. Note that 
Collada is mainly a format for digital content creation and integration into 3D worlds. 
X3D is a delivery and scene visualization format. 


Ideally, the Collada and X3D specifications can look like a standard workflow 
where Collada is a tool to create rich digital content and X3D is the medium on which 


74 Remi Arnaud and Tony Parisi. (2007). Developing X3D Web Applications With Collada and X3D. 
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that content is published or resides. Figure 88 shows the ideal Collada to X3D workflow 
in the context of building a web application. Media Machines recently released a Google 
Maps mashup where the user can peruse through certain specific buildings on a typical 
overhead orthographic view and click on them to bring up a 3D browser popup showing 


the buildings 3D model. The individual building models were a result of converting 
Collada files from Google’s 3D Warehouse into X3D using Flux Studio. Figure 89 
shows a screenshot of this. 



Figure 88. An ideal workflow for developing web applications using X3D and Collada 
from [74]. Note that Google Earth is in this model as one of the two main real world 
applications of Collada. In any future X3D-Earth initiative Collada can be considered an 
enabler for rich 3D building models just as it has worked for Google Earth. 
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Figure 89. Mashup created by Media Machines from [74]. The figure is showing a 
converted Collada (.dae) file shown in the browser as X3D. The mashup is an Ajax- 

based extension of Google Maps. 


J. GOOGLE 3D WAREHOUSE 

In this paragraph a methodology for importing KMZ files into Blender for further 
export into VRML or X3D is described. In the example, AT&T Park is downloaded as a 
KMZ file from Google’s 3D Warehouse 3D 75 Content Repository. The 3MB Google 
Earth Version and not the Sketchup 5 version is the file format that needs to be 
downloaded. The file can be found at: 

http ://sketchup. google. com/3 dwarehouse/details?mid= 193 3 f060194b3 cd9c7fa5 0fe56240 

75&prcvstart=0 . 


75 Google 3D Warehouse. (2007). Google. 
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figure 90. AT&T Park file available for download from [75]. Nearly all of the files in 
the system use the new Google Earth 4 Collada format called KMZ. 


K. IMPORTING KMZ INTO BLENDER FOR BUILDING MODELS 

Blender is currently one of the most articulate and well-supported open source 3D 
modeling tools on the Web. Blender’s strengths include its large user-base, forum-based 
approach for tracking bugs, and its ability to allow users within the Blender community 
to extend functionality by using a Python script plug-in. The current KMZ and Collada 
plug-ins in Blender 2.44 are a direct result of the preceding fact. By leveraging user 
efforts within their own open source community Blender is able to react quickly to 
changes in the marketplace and survive and stay relevant. 

The AT&T Park geometry will then be imported into Blender once the plug-in is 
correctly installed. At that point, the user still must texture the model manually. 
However, the KMZ file conveniently provides all the textures necessary once unzipped. 
The process of setting up the plug-in is a five-step process outlined in Figure 91. 
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1. Download and install the latest version of Blender 2.44 from www.blender.org 

2. Download and install the latest version of Python 2.5.1 from www.python.org 

3. Download the Python KMZ Import Script from: 
http://imsoler.free.fr/didacticiel/blender/tutor/py import kml-kmz en.htm 

4. Copy the .py file from Step3 into local Scripts Directory in Blender (typically): 
C:\Program FilesYBlender Foundation\Blender\.blender\scripts 

5. Reopen Blender and do a file->import and note the new KMZ import 
functionality 

figure 91. This is a basic outline of the five-step process to import KMZ into Blender for 

quick 3D building modeling. 



Figure 92. Location in Blender of new KMZ import functionality once the Google Earth 

plug-in is correctly installed. 
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Figure 93. Imported AT&T Park geometry in Blender. Textures for the model exist but 
still need to be manually added in the current version of the Blender Google-KMZ plug¬ 
in. 


The power of the preceding idea is that it allows for the X3D-Earth Working 
Group to possibly use content that is typically royalty free and in the public domain and 
to import that content into X3D. Currently, the 3D Warehouse is the largest repository 
for public domain 3D Buildings on the Web and is growing every day. The ability to 
drag and drop boilerplate buildings into X3D-Earth is a huge win for DoD Modeling and 
Simulation if they can successfully apply this technology towards a server-side X3D- 
Earth implementation. However, to do so directly from the 3D Warehouse might require 
DoD to partner with Google on mutually beneficial terms to secure Google’s permission 
to aggregate the 3D models into a production-ready X3D-Earth. In the interim, it is 
recommended that X3D-Earth avoid using 3D Warehouse models in any production- 
ready applications until such a deal is ever worked out. Until that time comes, if ever, 
X3D-Earth can apply the recommendations of Parisi, and Arnaud and utilize Collada as a 
tool for fast DCC. By using KMZ, i.e., integrating Collada with KML, X3D-Earth can 
support geospatial models that plug-in to Google Earth and likewise use any models from 
contributions within the 3D modeling community in a much more standardized way. 
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At first, the preceding may seem to be a contradiction in terms, in that the X3D- 
Earth project was intended to be open-source. For a moment though, consider the fact 
that even in an X3D-Earth environment where no partnership with Google exists, DoD is 
still paying employees, contractors, and third-party vendors, such as Planet 9 Studios a 
hefty fee already for building models. Furthermore, even the most open-source friendly 
platforms such as eBay, which runs on the Java EE platform, have proprietary nodes in 
the enterprise in the fonn of Microsoft servers for certain tasks. Again, the goal of open- 
source is not to paint the enterprise up and down with open-source. The goal of open- 
source is to minimize proprietary systems within the enterprise while still remaining 
flexible enough to insert proprietary nodes when they make sense. The main point to 
take away is that while it might be possible to obtain a handful of open source 3D 
models, the aggregation of a whole collection of professional-grade models for numerous 
cities and platforms throughout the world is going to cost money if it is to be done in any 
reasonable amount of time. The preceding is an unfortunate reality. 

L. LIMITATIONS AND OPPORTUNITY: GOOGLE 3D WAREHOUSE 

LICENSING STRUCTURE 

Based on Google’s current 3D Warehouse Terms of Service 76 it might be in the 
interest of the DoD to attempt to create a partnership with Google based on the sheer size 
and quality of the models in the 3D Warehouse in order to obtain permission to aggregate 
the 3D into an open source geospatial system. At first, the notion of Google accepting 
such a partnership might seem unlikely. However, thinking back to the days of Microsoft 
vs. Apple, one of the reasons Microsoft got as big of a lead as it did was through the 
aggressive formation of partnerships in industry. Historically, Microsoft crushed 
competition with the leverage from its operating system paired with its many partners. A 
DoD partnership with Google Earth on mutually acceptable terms might dramatically 
affect their biggest rival, Microsoft and its Virtual Earth product which some say has 
made recent gains on Google Earth owing to it’s more robust building generation 
algorithms. Currently, DoD pays myriad contractors to generate building models for 
simulations, which of which already exist in aggregated fonn in the 3D Warehouse. The 

76 Google 3D Warehouse Terms of Service. (2007). Google. 
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terms of service of Google’s 3D Warehouse are specifically nebulous for their own 
protection with regards to actually aggregating the models into a geospatial system in that 
they do not emphatically prohibit the aggregation of models under their terms of service 
but rather obligate the interested party to obtain their pennission to do so. To own such a 
system today the DoD needs express permission from Google to aggregate the models in 
3D Warehouse. However, doing so is clearly the lesser of two evils for two reasons: 
breadth and the su nk -cost of obtaining 3D building models. 

The first is that the DoD infrastructure for creating a huge model repository with 
as large a breadth from within DoD is simply non-existent. The DoD does do certain 
things very well however, such as modeling 3D weapons platforms, which is an area in 
which Google’s 3D Warehouse cannot compete. Furthermore, the DoD can most 
certainly model its own bases much better than Google might ever dream. However, if a 
true geospatial system is desired by X3D-Earth, entire metropolitan areas need support 
not just the gated contents of military bases. Similarly, the DoD cannot attempt to 
compete with Google 3D Warehouse in terms of modeling commercial 3D buildings as 
the infrastructure and experience is simply not there. While it is true that several smaller 
archives exist, a geospatial system needs models aggregated on a large scale and it also 
helps if the models are commonplace enough to already be recognizable by users who 
have experience in geospatial system domains like Google Earth. Additionally, even if 
the DoD did setup a high-profile web-based repository of 3D models what might prevent 
3D Warehouse models from continuously being uploaded as original-content and causing 
additional liability concerns for the DoD in either case? The answer to the preceding 
question is of course like anything in computer science, i.e., another level of abstraction 
or in this case having to impose additional moderation and cleanup functions on the 
repository. The question X3D-Earth must answer is whether that effort will produce a 
system of models that the DoD can use both in and outside the gated perimeter in a 
reasonable amount of time. 

Second, is that historically the DoD has contracted out the modeling of 3D 

buildings continuously anyway. The acquisition of a library of professional-grade 3D 

models will typically incur a cost because they take too much expertise and man-hours to 

build. If the DoD is perfectly willing and able to pay Planet 9 Studios or any other third- 
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party vendor or contractor to incorporate models in to their simulations why not partner 
with the best of breed? Planet 9 Studios certainly cannot compete with Google, on a 
geospatial level, and if the DoD is paying money for 3D buildings they need to come 
from the best-received and most cross-platform format, which is the KMZ archive file 
format, based on KML and Collada. Industry support and momentum count and when 
Google along with the Khronos Group agree that Collada can be used for an interchange 
3D building format, that holds a lot of weight. In Google Earth’s application of the 
Collada format for 3D buildings, a disruptive technology was practically applied and just 
like with all disruptive technologies it pays to be partnered with an early adopter and 
invest in the technology, which will exponentially grow and provide the enterprise which 
cheaper and more flexible future opportunities as a result. It is always more expensive to 
be a late adopter. 

M. LACK OF METADATA IN GOOGLE 3D WAREHOUSE 

While Google’s 3D Warehouse is certainly an example of a successful 3D 
building repository it has a few big problems. The first is the lack of professional grade 
military models, which is where Savage Model archive thankfully steps in to the benefit 
of the entire DoD. Savage Model archive is an excellent example of how the DoD can 
produce excellent models of things within its own domain. The second and crucial 
problem is lack of metadata. The preceding is where the Savage 3D Model archive at 
NPS can also help. Google 3D Warehouse can also learn a lot from the Savage Research 
Group at NPS, and actively work to more precisely define models within their archive 
through the use of meta-data. In 2006, Travis Rauch 77 wrote a thesis concerning Savage 
Modeling and Analysis Language (SMAL) for Tactical Simulations and X3D 
Visualizations. In this work, Rauch’s main argument is that SMAL can be used to feed 
simulations important data about 3D entities by extracting out meta-data such as range, 
flight envelope, et al. In short, Rauch argued that by utilizing metadata modern day 
simulations can plug-in to the metadata to provide real value to the simulation instead of 
just existing as geometry as has been the way of doing business in the past. Figure 94 

77 Travis Rauch. Savage Modeling Analysis Language (SMAL): Metadata for Tactical Simulations 
and X3D Visualizations. Master’s Thesis, Naval Postgraduate School, Monterey, California, March 2006. 
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outlines Rauch’s notional SMAL architecture. Note the central emphasis placed on 
metadata in the diagram and the reference to the Savage Model archive. 



INTERFACE LOGIC 


Figure 94. Diagram from thesis work done by LCDR Travis Rauch in 2006, outlining the 
ability of metadata to be used directly in the simulation to drive the characteristics of 
entities. Such characteristics might notionally be things like weapons or flight envelopes 
and ranges of various DoD platforms from [77]. 


In September 2006, LT Patrick Sullivan, USN wrote a landmark thesis entitled 
“Evaluating the Effectiveness of Waterside Security Alternatives for Force Protection of 
Navy Ships and Installations using X3D Graphics and Agent-Based Simulation.” 
(Sullivan 20 06) 78 . In the work, Sullivan outlines a methodology for incorporating 

78 Patrick J. Sullivan. Evaluating the Effectiveness of Waterside Security Alternatives for Force 
Protection of Navy Ships and Installations using X3D Graphics and Agent-Based Simulation. Master’s 
Thesis, Naval Postgraduate School, Monterey, California, September 2006. 
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metadata-rich models from the Savage Model Archive into Savage Studio to potentially 
train DoD service members on various aspects of Waterside Force Protection. Due to its 
current lack of metadata, Google 3D Warehouse models would be unable to be as easily 
plugged-in to Savage Studio as native Savage Model Archive models. 

In September 2007, LT Wilfredo Cruzbaez, USN wrote a thesis based again on 
the practical application of SMAL to complete learning objectives. The work is entitled 
“Effectiveness evaluation of Force Protection Training using Computer-based Instruction 
and X3D Simulation” (Cruzbaez 2007) 79 . The thesis is based on a formal usability study 
to evaluate the effectiveness of using Savage Studio as a training tool for Waterside Anti- 
Terrorism / Force Protection (AT/FP). The value of SMAL for training is that with 
SMAL, Savage Studio allows for simulation-entity properties such as “center of gravity” 
or “cruise speed” to be dynamically altered during the exercise to attempt to meet specific 
learning objectives. The final product of the Cruzbaez thesis is a Computer Based 
Training Course (CBT) that is learning-objective-based and effective. In the work, 
Cruzbaez found statistical significant results using Savage Studio as a CBT based on the 
administration of a pre-test and post-test on AT/FP doctrine. The results of the work 
showed that there was an approximate 40% increase in the AT/FP post-assessment score 
of subjects after completing the CBT-based training in Savage Studio. 

N. CONCLUSIONS 

Geospatial information is less useful if it cannot be put into contexts. By 
contexts, roads, street names, metadata and points of reference in general are implied. 

Due to its widespread acceptance by industry, KML is a useful tool in providing an 
information overlay on 3D terrain data. Since KML is XML-based it is inherently GIG 
compatible and ready to be integrated with other systems out of the box. Furthennore, 
the context of geospatial visualization improves by orders of magnitude with the ability 
to overlay 3D buildings and provide features like demographic data such as population or 
crime-rate, on mouse-rollover with server-side event listeners. To accomplish the 

79 Wilfredo Cruzbaez. Effectiveness evaluation of Force Protection Training using Computer-based 
Instruction and X3D Simulation. Master’s Thesis. Naval Postgraduate School, Monterey Ca. September 
2007. 
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preceding in an open-source context and minimize cost, the utilization of commercial 3D 
content on Google’s 3D Warehouse is recommended as long term goal for X3D-Earth if 
any agreements are reached with regards to terms of use. At the same time X3D-Earth 
can use the Savage Model Archive to provide geospatial content and meta-data for 
military-related content. Until then, and until such a deal is ever in fact reached, it is 
recommended that X3D-Earth use models exclusively from the Savage Archive or Nasa 
World Wind’s small library of 3D building models. Numerous commercial tools exist to 
import Collada buildings into the X3D format, along with a few open source tools such as 
Blender and Flux Studio. Through the application of both heavy reliance on KML as a 
standard for geospatial overlays, and Collada for 3D Buildings the X3D-Earth initiative 
can make fast headway on a moderate-cost alternative to contracting out their commercial 
3D modeling requirements. 
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IX. REZ TERRAIN DATA CONVERSION INTO X3D 


A. INTRODUCTION 

For a geospatial system to work, two things must be acquired. The first is 
obtaining the necessary orthographic imagery of the area you are interested in. Such 
imagery is often substantial in square pixel size, (read thousands, i.e., 10000 x 10000 not 
hundreds). Such imagery is also fairly easily obtained by going to the United States 
Geological Survey (USGS) Seamless Data Distribution Website 80 or by utilizing a third- 
party application such as Global Mapper 81 . Once the imagery has been obtained a image 
slicing scheme must be agreed upon and applied to the image to produce the effect of 
varying levels of detail as the user zooms in and out which is illustrated in the Figure 106. 
Finally, a program needs to exist which maps the myriad tiles, which are produced by the 
image sheer on to 3D terrain data. For the longest time, X3D and specifically the X3D- 
Earth Working Group did not have such a tool. However, with the introduction of Rez 
now it does, which means that a server-side 3D Earth implementation is now a real 
possibility. 

B. REZ OVERVIEW 

The Rez binaries and source can currently be found on http://planet- 
earth.org/Rez/RezIndex.html . According to author Chris Thorne, Rez is a terrain file 
parser and translator framework 82 able to output a single tile or a series of multi¬ 
resolution tiles. Rez is written in Java and is licensed under the GNU GPL (General 
Public License). The idea for utilizing the power of Rez to generate 3D cities actually 
came from attempting to integrate Ajax and X3D into the previously described Ajax Web 
Prototype Application that had been written for Naval Postgraduate School Research 
Professor Arijit Das, and his Mobile Device Checkout requirement. After successfully 
getting the prototype working with the ZK Framework, the next logical step was to 
attempt to graphically show registered-users in the system that had overdue mobile 

80 USGS Seamless Data Distribution System. (2007). USGS Website. 

81 Global Mapper Homepage. (2007). Global Mapper. 

82 REZ Design Architecture. (2007, June 26). Rez Source Forge Homepage. 
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devices. To do this, at the time, a simple Ajax tab panel was added to the reports page. 
At first, a simple X3D Model of the Earth was used for proof of concept. Once the tiled 
3D Earth was embedded into the Ajax control and the performance and aesthetics of the 
model were acceptable, the realization that you can build entire geospatial systems this 
way came to mind immediately. From that point, a desire was produced to auto generate 
the first X3D-Earth city model with multiple levels of detail. The idea behind this was to 
essentially be able to show a local city such as Seaside, California and in a similar 
fashion to Google Maps show red balloons where late users resided according to the 
address they provided at registration time. Figure 95 is a ZK tab panel in the first Ajax 
Prototype application that was developed for the Naval Postgraduate School Mobile Lab. 
Note that the 3D Earth example was generated by Rez and is embedded within the panel 
of an actual Ajax tab panel control, not a div tag or table in a webpage. 



Figure 95. The Earth tiled at two levels of detail (LOD) within an Ajax ZK tab panel 

control. 
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(Mobile Checkout Admin Window 


| View All Checked Out Retro | View Checked Out Items Map 
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Print Report | Email Report | Send Late Noiice(s) | Mark Checked Hem(s) As Returned | 


Figure 96. An Ajaxian Tab Panel reporting of checked-out mobile devices/books 


After working closely with Dr. Byounghyun Yoo, at the Naval Postgraduate 
School, and after approximately a month of working with the Rez API, a breakthrough 
occurred when we attempted to import elevation data using VRML rather than the more 
technical GeoTiff or DEM formats. Rez currently supports multiple input formats 
GeoTiff, DEM, DTED, and VRML being just the few that it can support. However, at 
the time the notion of using Rez was new, and as novice users we needed the simplest 
implementation just to get a model to serve as proof of concept. By realizing that 
importing elevation data in VRML was indeed dramatically simpler, modeling cities with 
Rez became a reality. After running the Rez GUI front-end, which calls the Rez Java- 
based executable, it took about 15 minutes to build the first auto-generated X3D-Earth 
model of a city, Oakland Harbor to be specific. Shortly thereafter, Dr. Yoo produced a 
set of slides with the intent of showing others how this automated process can work for 
any city. At this point, the next step is creating a viable server-side architecture that can 
effectively create the illusion of scrolling in the 3D Browser. Once that is accomplished 
there is no limit as to what this technology can accomplish. The slides are included 
below as a set of figures with a link given as well for more in depth exploration by the 
interested reader. 
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Figure 97. Diagram showing the basic idea behind LOD tiling from [68]. Note that as 
the client zooms in the amount of tiles representing the terrain start to increase 

exponentially. 



Figure 98. A diagram of the LOD concept where the image sharpens as the distance to it 
decreases from [68]. Note how the target node changes in X3D from Billboard to 
IndexedFaceSet to Cone, as the user gets closer to the target node. 
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c. 


STEP-BY-STEP INSTRUCTIONS FOR GETTING STARTED IN REZ 


The set of slides presented in this thesis can be found at 
http://www.byoo.net/x3d-earth/ . 

The prerequisites for successfully running through the example slides are an 
installed Java Development Kit 1.2 or greater, and Global Mapper 8, 
http://www.globalmapper.com , and of course Rez (imageSlicer and Rez binary fde). It is 
important to note that orthographic data from the USGS can be used in a similar manner 
to build a more open source solution, however, for the novice Rez-user Global Mapper 8 
provides a much richer interface and is therefore used in the exemplar application 
concerning how Rez works. 



Open Your Own Data Files 


(Menu Commend FNc >oo< 




Find Data Online 

(Menu Commend File --Find Date Onftne) 


Download Free Maps/Imagery 
from TerraServer-U SA/WM S 



Display Settings/Projection 


-M* Manage Loaded Data 


Figure 99. Step 1: Download Orthographic Imagery from Global Mapper 8 by clicking 
Download Free Maps/Imagery from TerraServer on the Global Mapper home screen. 
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Figure 100. Step la: Select Download Urban Area High Resolution Orthographic 
Imagery and then give Global Mapper an urban city and press Ok. 



Figure 101. Step lb: City will load tile by tile and the orthographic imagery will be very 
high resolution (street level). At this point the user can choose various means of 
exporting the orthographic imagery from the File Export menu, i.e., jpeg, GeoTiff etc. 
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Figure 102. Step 2: A diagram showing downloaded elevation data. In Global Mapper 
navigate to the main menu and choose to view DEM format. The next step is to export 
the terrain data for Rez (VRML Elevation is one of the easier formats to export but most 

other formats are also supported by Rez). 
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Figure 103. A diagram showing Baltimore Harbor DEM data in Global Mapper 8. 



Figure 104. Step 2b: Under the File->Export menu in the upper-left choose to export the 
elevation data in any format but VRML (.wrl file) is typically very easy and 
recommended. This is an example of DEM data from the San Jose area being exported to 

VRML. 
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Figure 105. An example of VRML elevation data from GeoMapper once successfully 

downloaded from [68]. 




Running 


□ imageSlicer 

• java -XmxlOOOM -classpath .;.\slice.jar SmoothlmageSlicer 
"D:\...\baltimore.jpg" 0 8 n 512 512 y n n 

• Parameters: 

- start level of LOD tree 

- end level 

- verbose flag ("y" means print useful messages for debugging) 

- x dimension of output image (pixels) 

- y dimension of output image 

- binary/quadtree flag: "y" means produce quadtree 

- gif image output flag : "y" means generate gif images 

- geoVRML flag : "y" means format names of images to match the 
south-north grids of geovrml 

Or. i \i i unc / nc i o / u t- ^^^^THE MOVES INSTITUTE 

o Byounghyun Yoo / NPS / 2007-05-18 / www.byoo.net . ...... 


Figure 106. Step 3: Run the imageSlicer to generate tiles at various LOD to match the 
specifications and needs of any specific project. Figure 106 showcases a few of the most 
important command-line switches that the imageSlicer can handle. Figure 106 is from 

[68]. 
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Running 


□ Rez 

• java -DdebugOn=false -classpath ./Rez.jar rez.Rez testX3D.txt 0 8 1.2 n y 0 1 0. 

1 100 100 0 0 n 

• Parameters: 

- configFile: configuration file 

- firstTreeLevel: starting tree level 

- finalTreeLevel: final tree level 

- detailScale: a scale factor applied to adjust detail (LOD range values) 

- gzipFlag: to compress the output files 

- samplingFlag: turns on sampling of tiles to reduce number of polygons in low level of d 
etail levels. For performance improvement. 

- Samplinglncrement: the number by which the sample size is increased 

- horizontalScale: the number by which the terrain size (x and z dimension) is multiplied. 
Must be 1 for GeoElevationGria output 

- heightScale: The number height is multiplied by (reducing height tends to improve perf 
ormance). 

- minOutputTileDimension: min and maximum output tile dimensions when sampling larg 
e input tiles 

- maxOutputTileDimension 

- translation x: it may in some cases be necessary to apply translations (scaling not alway 
s enough) 

- translation z 

- treeType: generate binary tree(y) or quadtreee (n) 
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Figure 107. Step 4: Run Rez to overlay the VRML (or additional format) elevation data 
with the LOD image tree to generate X3D. Figure 107 is from [68]. 


Features 


□ Inputs: 


• Apart from the input elevation file(s), important inputs are the plugins for input d 
ata parser, scene generator and output tiler. 


- DTED (plugins/ParseDTED) 

- vterrain.org BT format (ParseBT) 
gtopo30 or DEM (ParseTopo plugin) 

- Etopo5 (ParseETopo5 plugin), etopo5Asci 

- Asci (ParseAVAscii plugin, or ParseAVAsciDegrees) - e.g. from ArcView asci export 

- Asci xyz data 

- Arcview bil (ParseAVBil plugin) 

- VRML ElevationGrid (ParseEG plugin) 

- GeoVRML GeoElevationGrid (ParseEG plugin, or ParseEGDegrees) 

- General grid style height fields: the (ParseAVAscii can be used to parse a simple asci gri 
d height field and the bil parser can be used for binary (16 bit float) height fields. Howe 
ver note the header information needed in the install instructions. 

- convenience versions of ParseAVAscii and ParseEG that assume the grids are measured 
in degrees rather than meters. 

- parsing xyz data 
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Figure 108. Slide showcasing the various formats that Rez supports for terrain data. 

Figure 108 is from [68], 
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Feature 


□ Outputs: 

• output tile generator plugins for: 

- Combined VRML tile- for creating one tile from multiple tiles (combinedVRML/Combiner 
Tile) 

- Combining then splitting (VRMLCombineSplit) 

- Comact binary tree output (compactBSP/CompactVRMLTile). 

- Compact binary tree output that only outputs a slice (compacBSPSlice/CompactVRMLTil 
e). 

- Comact binary tree output with PixelTextures (compactBSP/CompactVRMLTilePix) 

- ContouredJpeg - the height data in colour bands (pretty limited) (contouredJpeg/Conto 
uredJpeg). 

- Cutting a rectangular pice out of a grid (compactBSPCut) 

- Slicing a piece of terrain off a grid (compactBSPCut) 

- GeoVRML working group GeoElevationGrids (geosurface/GeoVRMLTIle). 

- Geospatial X3D output (experimental still). (geoX3d/GeoX3DTile). 

- GreyScale jpeg (heightMap/GreyScale) 

- Gtopo - a binary height grid format with separate .hdr files (gtopo/GtopoTile) 

- Height map - just converts height values to integers then into RGB encoding ((heightMa 
p/HeightMap) 
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Figure 109. Slide showcasing the various formats that Rez supports for X3D output. Note 
that Geospatial X3D is supported but is still in alpha testing. Figure 109 is from [68]. 


Example 
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Figure 110. Screenshot of Rez imageSlicer running in a terminal. In the lower right 
portion of the diagram a file view of the individually sliced tiles is shown as they might 
appear in a directory-view on a typical Windows machine. Figure 110 is from [68]. 
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Figure 111. In the left section of the diagram, the GUI tool for Rez is shown which allows 
a user to set the most common Rez parameters such as levels of detail or tile dimensions 
from [68]. In the future, a GUI upgrade for Rez is strongly recommended. In the right 
section of the diagram, Rez is running in the terminal doing the work of overlaying 
orthoimagery on top of elevation data and then mapping the result to X3D tiles. 



Figure 112. An auto generated Rez output in X3D of Oakland Flarbor from [68]. 
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D. REZ CONCLUSIONS AND RECOMMENDATIONS 

While Rez is clearly an enabler for the X3D-Earth project, it has several areas that 
need the immediate attention of the X3D-Earth Working group to fully realize its 
potential such as image slicing, and exhaustive testing of Rez produced Geospatial nodes. 
It is recommended that the Rez imageSlicer be optimized. The imageSlicer currently 
uses more memory than the average user’s laptop can possibly afford to yield. Therefore, 
current Rez models are forced to use a lower resolution than the current orthoimagery 
allows. Normally the orthographic imagery is significantly better than the Rez 
imageSlicer can support. Currently, the Rez imageSlicer is a Java application without 
any GUI interface. The imageSlicer uses JNI (Java Native Interface) to call Sun’s C 
Libraries, which is also a concern and generating compile time warnings. As of Java 
Development Kit 1.6 the legacy methods are currently deprecated. The concern with the 
proprietary libraries is that they may get dropped from the next Java Development Kit 
release. 

Another issue arose which suggests a possible Rez rewrite to support the tile 
format used by Nasa World Wind. Figure 113 shows Nasa’s current format 83 , which is 
supported in Global Mapper 8 through direct tile export (although this process literally 
takes hours). The preceding process is also what dstile, Nasa World Wind’s tiling- 
software, uses. In the future, if the X3D-Earth Working Group wishes to partner with 
Nasa World Wind Geospatial Services, it makes sense for the tiling systems to be the 
same. 


83 Nasa World Wind Tiling Schema. (2007). Nasa. 

127 



WWHWnd MtpTIK ?pSWfH 


wji m*i«Ti»5«j-tn ihr- lljlp ! jura pqprfcpn 
;jkj grajnjfitw pnvtre IK-r» li.*i™T.Y*=rin iV.ipi In lit* i 
irrtjK-ijti'^r mg^CJil jin-l jk-.i ru|: n v; j Lt*vw 



' >■* I: iv Ijirr mIh» wnridmhi fe :■ 

iijMinr| jti I pv-' O 


LtxHD 

56 ikhjiiSFt 

Wbta 

u™d l 

lafe^im. 

MM eta 

u*di 

QddPta 

SMota 

l*«dJ 


3HI«k 

Lfe-dn 







i 


I lt |irif‘Hih ivr iMcvn,Ufe«4dWWid-ilrHPi niLrfhgfe-iaptaiJ 

Ittf urrtf inj|i in tuLiritrMrtm^tm irvi^iriioiib Eah ^Jrtunriiftxyn 

■qL^Jigtol '■Sr iPLinlpii l- 4 bkpk ;Hr3-unp|. 




hKM4r i * VI k x VI j |H'.tI v :ii i m liul i an 
tH* ijK^HPd III Ail, IIILt^* I :— jf. Wjxll 

J*v u.ri rt:. FtartCriftpoii ll'-r^ui-r n 
vlirnl n IIk" IimbJ tattler nfcndt. 


Wll__ 



- 

(E 

r 

? 

■ 

r *■' 




U 





- 



: ’ 



% 






A 

r 









■ - 





k 







* 


fftfll l>»l 


rv nwJMi 

l(u '.V-UdV.'.r.i |r#ta IM 

**ta*rrVdr<>n'« 
.XvH a vhMmi 


WWW f|- i-J iKmil eta .* 4i_4 V-i tXMddt-ifcUj Irvft. 
CiK"i>ii»li‘ i^S'iTULtaT-i! SHMd >■ life •&-*■& Iht Olr 


1 D«CA\D 4EbS«rt *1MH \ M<l ***$ ,iL*. 


3 ZZ 5 ZTJ 1 XIII 





-1 



>ffa MCri 







t-ynpk-, 

CVn^Mi F4tf.h*iAiWaft*WKi!d IA 
{EM»'.E4nW>Bk4MirtltTMnJtai0i(i«2i«Hl i»)7*U 



n*l»Vt kuHiiMii 
Ljt^h Nunim: O 
Mow I 

£oiurrn: f 

I map* Fuptm£ DO'S 


Figure 113. A diagram of Nasa World Wind’s current tiling schema from [83]. 


The testing of the integrity of the Rez generated Geospatial Nodes is currently 
ongoing and being led by NPS Visiting Post Doctorate Researcher Dr. Byounghyun Yoo, 
Rez creator Chris Thome, and Associate Professor Don Brutzman. Once the Geospatial 
Nodes have been tested as accurate on both the Rez-end and various client-side browser 
implementations such as Xj3D, the potential for creating X3D geospatial systems using 
Rez across the full scope of the Earth will be excellent. 
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X. 


INFORMAL GOOGLE EARTH USABILITY COMPARISON 


A. INTRODUCTION 

Usability can either make or break a system. Over the years, Jakob Nielsen has 
emerged as one of the industry’s foremost experts on the topic 84 . One of Nielsen’s most 
important concepts, yet when thought of seems common sense, is that any and all content 
that is extremely important to the context of a prospective web site needs to reside in the 
upper left corner of the screen, at least for cultures where people read from left to right. 
Nielsen also stipulates that with today’s current technology most users give up on a site if 
it does not come up in less than five seconds. Surprisingly enough, many web sites and 
desktop applications as well violate this first basic rule of thumb. 

Owing to the fact that the X3D-Earth Project’s scope is so massive, it seemed like 
a good idea to do a usability study on the two major Geospatial players, Google Earth and 
Nasa World Wind, so that when X3D-Earth gets implemented the successes and mistakes 
that were made in both respective systems are considered in X3D-Earth. Figure 114 is a 
summary of Nielsen’s work with Web Page delay and showcases the effect on the user 85 . 


Delay <0.1 

No delay noticed 

0.1 < Delay < 1 

Delay noticed by user but thought flow not interrupted no 


progress indicator required 

1 < Delay < 10 

Progress Indicator Needed 

Delay >10 

Major delay, user needs detailed message here 


Figure 114. Delay Table based on Jakob Nielsen’s Work Outlining Client Patience 
Threshold on the Web from [83]. Note that a progress indicator is typically needed if the 


client experiences a delay between 1 and 10 seconds. 


84 Jakob Nielsen. (1999). Designing Web Usability. 

85 Jakob Nielsen. (1994). Response Time: The Three Important Limits. 
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B. OVERVIEW 


In March of 2007, an informal usability study between Google Earth and Nasa 
World Wind was conducted to attempt to find the best practices in modern terrain system 
design. From the study, the relative superiority of Google Earth to Nasa World Wind 
with regards to usability was demonstrated. Major factors, which were instrumental in 
the preceding, included the integration of the Google Browser into the terrain system, 
particularly in the upper left corner of the screen where most people focus their attention. 
Secondly, in Google Earth the detailed urban orthographic imagery layer is a given as it 
is set to display at a default setting. Nasa World Wind has a default setting of no urban 
orthographic imagery layer; most likely for performance reasons. The detailed results 
and methodology of the study is included in Part D below. 



Figure 115. Run time screenshot of Google Earth User Interface running on Mac OS X 
from [73]. Google Earth runs on most platforms including Mac OS X while Nasa World 


Wind runs solely on Microsoft Windows. 
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Figure 116. A Google Sketchup model of Alcatraz Island from Google Sketchup. (2007). 
Google. Retrieved July 14, 2007 from http://sketchup.google.com . Sketchup is an 
excellent 3D modeling tool for allowing “mere mortals” to create and publish content 


onto Google Earth. 



Figure 117. The Nasa World Wind user interface from [83]. 
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C. TEST METHODOLOGY 

The experiment was conducted in the Savage Lab within the Moves Institute at 
the Naval Postgraduate School in Monterey, Ca. The experiment was conducted on a 
Toshiba Satellite A75-S213 3.3GHz machine with 1 GB of RAM. Before execution of 
the tasks, video was recorded of the screen using a Canon DC 10 4 Mega pixel DVD 
Camcorder. During the execution of each task, users were given absolutely no 
instruction or guidance on how to use either system. 

Each of the users were asked to complete the following tasks and instructed that 
under no circumstances were they to feel pressured to complete all or any of the tasks in 
the 30 minutes of allocated time. The only thing that was asked of the users was to 
alternate between using Google Earth and NASA World Wind as they traversed the task 
list. The users were encouraged to keep their efforts stress free and fully allowed to skip 
entire tasks entirely once they became too difficult. When a user was finished with the 
experiment, to their own level of satisfaction, they were asked to stand up and fill out a 
post-assessment form on an adjacent table. 

1. Locate and find Caesar’s Palace in Las Vegas, NV 

2. Locate and find the Senate in Washington, D.C. 

3. Find approximate point-to-point distance between top of Washington Monument and 
the top of the U.S. Capital Bldg. 

4. Locate and find your house. 

5. Locate and find eBay in San Jose, Ca 

Figure 118. Task list for the Google Earth vs. Nasa World Wind Usability Study 
conducted at the Naval Postgraduate School Scene Authoring for Advanced Graphical 
Environments (SAVAGE) Research Laboratory in 2007. 

D. RESULTS 

The results of the study are pretty clear, at least for the assigned tasks. In almost 
every instance, Google Earth was preferred over Nasa World Wind. In this study the 
subjects’ preference for Google Earth was approximately 2:1. Incidentally, the rate at 
which subjects aborted tasks in Nasa World Wind compared to the rate at which tasks 
were aborted in Google Earth is also approximately 2:1. Figure 119, shows the raw data 
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collected during the recording of the video by later analyzing the video for mouse 
completion and time clicks, completion times are measured as a matter of minutes and 
seconds. 


Task 

Completion 

Completion 

Google 

Nasa 

Task 


Time Google 

TimeNa&a 

clicks 

dicks 

Abandoned'’ 


(min sec) 

(nun. sec) 




1-1 

2:26 

6:55 

28 

29 

No 

1-2 

1:42 

345 

3 

8 

No 

14 

I 59 

1 10 

21 

8 

No 

1-4 

047 

246 

4 

39 

Yo-World Wind 

14 
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547 

10 

59 

No- 

2-1 

145 

3:13 

1 

22 
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4 

8 
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24 
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16 

22 
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9 
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24 

(T26 
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1 

12 

Yo-World Wind 

J-l 
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619 

1 

11 

No 

5-2 

306 

458 

9 

12 

Yo-World Wind 

3-3 

2:12 
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6 

8 

Yo-Warld Wind 

14 
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1 

5 

Yo-Warld Wind 

3-3 

3:11 

0:43 

15 

6 

Yu-Warid Wind 

4-1 

109 

926 

6 

52 

Yo-Warld Wind 

44 

346 

1 29 

53 

11 

No 

4-3 

141 
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5 

3 

No 

44 

102 

436 

3 

8 

Yo-World Wind 

4-3 

248 

1:32 

t 

14 

No 

3-1 

200 

241 

21 

8 

Yo-Warld Wmd 

34 

146 
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17 

11 

No 

34 

2:43 

503 

25 

52 

No 

3-4 

300 
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25 

14 

Yo-World Wind 

5-5 

122 

5:26 

7 

33 

Yo-Warld Wind 

4-1 

045 
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2 

16 

Yo-Warld Wind 

6-2 
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343 

23 

15 
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3:44 

8 

22 
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2 

15 
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2 

11 

No 
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2 

24 

No 

74 
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9 

30 

No 
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243 
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18 

41 

No 
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2 

14 

Yo-Warld Wmd 
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017 

2:23 

2 

11 

Yo-Warld Wmd 

6-1 

209 

3:06 

8 

9 

Yo-Warld Wmd 

64 

1 46 
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13 

23 

No 
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243 

5 

7 

No 
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4 

16 

No 
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9 

31 
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Figure 119. Average user-time to complete a task between Google Earth and World Wind. 
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Overall 

Satisfaction 

Google 

Earth 

Nasa World 

Wind 

Participant 1 

6 

2 


Participant 2 

6 

4 


Participant 3 

6 

1 


Participant 4 

7 

3 


Participant 5 

5 

5 


Participant 6 

7 

3 


Participant 7 

5 

2 


Participant 8 

4 

2 


Participant 9 

7 

3 


Participant 10 

6 

4 






Avg Satisfaction 

5.9 

■ 







Figure 120. Average subject-satisfaction level between geospatial systems in the Google 
Earth vs. Nasa World Wind study based on a ten-point scale. 



Figure 121. 


Average subject-satisfaction chart showing the nearly 2:1 preference subjects 
had for Google Earth over Nasa World Wind. 
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Figure 122. Average time per task in Google Earth and Nasa World Wind Usability Study. 
Note that on average World Wind tasks took nearly twice as long to complete as their 

Google Earth counterparts. 
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E. DISCUSSION AND RECOMMENDATIONS 

From this experiment it quickly became clear, even without the participant video, 
that users preferred Google Earth to Nasa World Wind. The most telling aspect of this 
comes from the task-abandoned category, which only shows tasks abandoned while the 
participants were using the Nasa World Wind system. In no case, during the study, did a 
participant abort any task while using the Google Earth system. 

It should be noted that significant further development has occurred with each 
system, and that a formal study was not conducted. A needs analysis and formal study 
along the lines of the work of LT Wilfredo Cruzbaez might well yield different results. It 
is recommended that such a study be conducted. 

From the post-assessment questionnaires that were administered to all 
participants, in this study, the same conclusions were registered. In every instance, users 
rated Google Earth easier to use in each category, i.e., General Navigation, Vacation 
Planning, and Topographic Data etc. From the same questionnaire, participants were also 
in general agreement that the most important control, in terms of easing navigation, in 
both systems, was an integrated web browser. This study asserts that part of the problem 
with usability in Nasa World Wind was the fact that there was no integrated web browser 
within the visible 3D Window. In Nasa World Wind, a “Place Finder” option allowed 
the user to bring up a Yahoo search tool but many participants found the preceding to be 
non-intuitive and even found the tool itself to be inferior to Google’s search engine. 

The second major problem that participants had with Nasa World Wind was the 
fact that, owing to the task listing, many of the general navigation tasks required users to 
zoom down to street level to complete the task. However, by default Nasa World Wind 
has its high-resolution urban orthographic data layer disabled. Of note is that feature is 
extremely easy to enable in World Wind. However, the problem is that, in this study, 
participants were all novices and many did not know the definition of orthographic and 
what an orthographic image is. The preceding spawned a whole slew of problems and 
frustrated users when Nasa World Wind did not produce an acceptable level of detail 
when the subjects zoomed into street level to find a specific location. Most likely, the 
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low default resolution was a conscious decision on the part of the Nasa developers to 
reduce system lag in order to increase performance. 

The third and final major problem that most participants had with Nasa World 
Wind was the fact that the Nasa servers frequently lagged and at times lagged severely. 
The preceding is why it is suspected that the high-resolution orthoimagery is by default 
disabled in World Wind. Oftentimes in the experiment, participants opted to start a task 
in World Wind and while the Nasa terrain data was still loading, they eventually switched 
windows to Google Earth to continue other assigned tasks in order to save time. 

F. CONCLUSIONS 

The major takeaway from this usability study is that customers do not have a high 
tolerance for non-intuitive interfaces. The major reason Google Earth outperfonned Nasa 
World Wind was not because of content, which was rather similar but rather because of 
the assumption by Nasa World Wind that their interface might be easy to use solely 
because of the Apple OS X style navigation system at the top of the screen. Although the 
preceding does have an element of truth to it as fisheye controls have shown to be 
preferred in at least some cases by a University of Maryland study 86 . The subjects did 
comment favorably about the OS X style menu bar, but were turned off by Nasa’s design 
decision to not put any search functionality at the first level of the user interface. While it 
is clearly functional, Nasa’s Yahoo-based search function is buried in the third level of 
their menu hierarchy while Google’s is in the upper left comer of the main screen-first- 
level (right where Jakob Nielsen might recommend it to be). Nasa World Wind might 
also have improved its user experience if the detailed orthographic image layer was 
turned on instead of off by default. When comparing systems, new users do not have 
patience and when they zoom-in to the street-level of a geospatial system it needs to be 
comparable to industry leaders Google and Microsoft or the customer will run (not walk) 
away. These preceding design considerations need to be integrated into any future X3D- 
Earth solutions. 


86 Benjamin Bedersen. (2000). Fisheye Menu Usability Study. 
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XI. CONCLUSIONS AND RECOMMENDATIONS 


A. CONCLUSIONS 

X3D-Earth has the ability to change the way the DoD does business. Detailed, 
high polygon-count models of Oakland and Baltimore Harbors, Panama City FI, and 
Indian Island have already been auto-generated by Rez and look professional-grade. 
Owing to the fact that multiple client-side solutions for geospatial systems exist such as 
Google Earth, Nasa World Wind, and Microsoft Virtual Earth, it might be in the best 
interest of the X3D-Earth working group to attempt to create a server-side solution while 
still solving important Anti-Terrorism / Force Protection (AT/FP) issues by continuing to 
integrate existing high polygon-count models into the Savage Studio discrete-event 
modeling tool. Furthennore, by leveraging existing open standards such as the Khronos 
Group’s Collada specification, DoD Modeling and Simulation can complement the rich 
3D content libraries for the myriad platforms under its umbrella with commercial 
building entities like skyscrapers and airports. The preceding is made possible through 
the widespread adoption of the Collada format for DCC and its popularity with 3D 
modeling heavyweights such as Autodesk and XSI. In doing so, the DoD can hopefully 
build up an even bigger repository that it already has with the Savage Model archive, 
while at the same time ensuring that Savage meta-data continues to be added to any new 
content for the description of various platform parameters at runtime. 

Ajax and Web 2.0 have the ability to provide the DoD, and in this case the Navy 
in particular with the rich-client user experience that many so often are missing because 
of NMCI. Ajax and Web 2.0 are extremely relevant in today’s Navy because many end- 
users feel powerless to run the types of applications on their machines that they actually 
feel they need and want but which are not NMCI-compatible. A great feature of the Web 
is that applications need not be deployed. With Ajax, the traditional paradigm of 
request/response has been replaced with a much smarter and intuitive asynchronous flow 
of information across the wire from client to server, and even from server to client if 
Comet is used. Again, nothing scales like the Web and nothing is as interoperable as 
XML. The DoD mandate for everything to be GIG compliant demands nothing less and 

thankfully for the Navy, Ajax and Web 2.0 deliver in spades. Google was the first to 
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show the power of Ajax when they created the first 2D geospatial system in Google 
Maps, and also pioneered a great 3D system as a standalone client-application. To really 
make a difference though in how the DoD and, more specifically NMCI operate, any 3D 
system needs to be on the server-side. A server-side Ajax3D-based X3D-Earth can 
alleviate many of the NMCI deployment issues that might inevitably arise from any 
client-side open source solution. Furthennore, a server-side solution can theoretically be 
ran on today’s class of smart phone, as wireless technologies get better and better daily. 
The end game is enabling the war fighter to visualize the battle space in almost any 
theater on almost any computing platform. With Ajax, Ajax3D, X3D, and Collada this is 
now possible on the Java EE platform. 

B. RECOMMENDATIONS FOR FUTURE WORK 

The ability now exists to easily create cheap city models. As of today, Rez can 
support Geospatial tiles; however, owing to the fact that many 3D browsers have yet to 
exhaustively alpha-test their own implementations any code currently produced will most 
likely crash at the browser plug-in level. Currently, the geospatial implementations on 
the Flux and Xj3D browsers occasionally crash when tested against geospatial tiles in 
practical application. 

X3D-Earth can obtain value from attempting to integrate X3D into modern day 
smartphones. Currently there is not much in tenns of research that has been done in the 
field of integrating modern day 3D plug-ins to the browsers on most smartphones. 

Today, the iPhone, in particular looks promising because of its broad user base and new 
and intuitive touch screen controls. Future work might concentrate on implementing a 
proof-of-concept demo on a modem day smartphone using Web 2.0 design principles like 
Ajax to build an effective UI, which drives an X3D server-side geospatial 
implementation. Industry has already made this shift as popular sites such as Digg, 
Amazon 87 , Google and Fandango already have functionality built into their respective 
enterprises that detect if the incoming internet protocol (IP) address is from a mobile 
device, specifically iPhones. If the IP of the client is an iPhone the preceding systems 

87 Amazon iPhone Beta Site. (2007). Amazon. 
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reroute to a customized UI that is both iPhone friendly and looks amazing on a 
smartphones smaller screen but still provides every bit of functionality as if the client was 
connecting via a normal PC. 



Figure 123. An illustration of an Ajax-based front-end specifically designed for the iPhone 
from Amazon.com. X3D-Earth could similarly design such an interface for a sever-side 
geospatial system. Advantages of the preceding are the touch screen interface and haptic 
controls such as the ability to zoom in and out by pinching inwards or outwards with 
finger and thumb on the phone’s main screen. 


Server-side X3D-Earth is the ultimate goal and might involve the setup of a 
framework that might likely be able to handle the huge amount of computation (most 
likely the NPS Cluster). The issue with the preceding might essentially be how often to 
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update the imagery and how fast the cluster might produce an actual Rez output, for a 
specific metropolitan area, from start to finish. Depending on the eventual system 
architecture and performance, it may be too costly to update the terrain data and 
orthoimagery of the entire system as often as desired. Instead, depending on how fast the 
NPS Cluster can create cities, updates may need to be scheduled at night and the system 
taken down. An alternative might be to potentially map entire metropolitan areas or 
regions to individual Java EE Enterprise Application Archives (EARs) each listening on a 
different port 8080, 8081, 8082 etc. From that point, only regions of the site might need 
to go offline for a certain time period, if at all depending on how the application server is 
setup. An EAR file consists of the necessary project files, class-referenced libraries, and 
numerous XML configuration files to run an enterprise-level application on the Java EE 
platform. For testing terrain or orthoimagery updates, modem day application servers 
support a concept called hot-deployment which means they are smart enough to be able 
to deploy modules without a server restart which is more useful for development and 
testing but generally considered unsuitable for production. 

A second major point of interest might be to emulate the current server-side 
architecture of Google Maps and attempt to retrofit that on top of current capabilities with 
3D browsers and Rez. Google Maps currently utilizes a servlet that calls individual tiles 
by latitude, longitude and tile zoom-level. Google Maps depends on two built in browser 
components, XMLHttpRequest and XSLTProcessor. Figure 124 is a code snippet of a 
typical call to the Google Maps Server. 88 


http://mt.google.com/mt?v=.l&x={x tile 

index}&amp;amp;amp;amp;amp;amp;{y tile index}=2&zoom={zoom level} 

figure 124. The above code shows a typical Google Maps server-side call. Figure 124 is 

from [88]. 


In Figure 125, a typical servlet call after a search on the city of Atlanta is shown. 
Note the q variable equates to the search field, the z equates to the level of zoom. The 
parameter, sll is for latitude and sspn is for span/viewing area. Google Maps uses XSLT 


88 Joel Webber. (2005). Mapping Google. 
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to process the XML into corresponding HTML. For a Server Side X3D-Earth, a similar 
approach can be applied with Rez being the Map Renderer (Google Maps has their own 
proprietary renderer). 

http://maps.google.com/maps? 

q=atlanta&z=13&sll=37,062500%2C-95.677068&amp;amp;amp;amp;amp;amp; 
sspn=37,062500%2C80.511950&output=js 

"igure 125. The above code shows a typical HTTP GET Request for a Query for Atlanta 

in Google Maps. Figure 125 is from [88]. 


<?xml version="1.0"?> 

<page> 

<title>atlanta</title> 

<query>atlanta</query> 

ccenter lat="33.748889" lng="-84.388056"/> 

<span lat="0.089988" lng="0.108228"/> 

<overlay panelStyle="/mapfiles/geocodepanel.xsl"> 

<location infoStyle="/mapfiles/geocodeinfo.xsl" id="A"> 

<point lat="33.748889" lng="-84.388056"/> 

<icon class="noicon"/> 

<info> 

<title xml: space="preserve"x/title> 

<address> 

<line>Atlanta, GA</line> 

</address> 

</info> 

</location> 

</overlay> 

</page> 

Figure 126. Incoming XML server response after an Atlanta query is issued by the client- 

side in Google Maps. Figure 126 is from [88]. 


Oftentimes, the hardest part after ingesting a lot of different acronyms and 
technology design patterns is detennining which direction is best to pursue after all is 
said and done. Currently, the most promising practical application of Web 2.0 for Navy 
Modeling and Simulation is to integrate Rez with an X3D-Earth Java EE-based web 
application to produce Google Maps style scrolling within an X3D Browser. The most 
obvious and effective application of Rez with Ajax can be to utilize Rez as a tool to 
create X3D content on the fly and periodically update the aforementioned data on the 
server-side, possibly on the NPS Cluster through nightly runs. In such a system, Ajax 
can be responsible for updating the X3D scene graph whenever the user drags into 
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another virtual latitude-longitude box possibly using an X3D GeoProximitySensor 
construct to do this. The Ajax capability can insure that the tiles are delivered to the 
client in a “Just In Time” fashion rather than pushing the entire set of tiles to the client at 
every state change. In such a scheme, only the relevant tiles along the new edges of the 
screen might be necessary and therefore added with the Ajax3D calls. Asynchronous 
streaming of server-side data using Comet can also be a distinct possibility if a normal 
Ajax3D client-side architecture provides inadequate tile loading times or has problems 
with scalability in practical application due to the server-side needing to constantly send 
updates to the client. 

To accomplish the preceding goal, the major X3D Browsers, i.e., Flux, Octaga 
and Xj3D, need to integrate working and functional Geospatial Nodes for which Re¬ 
generated models can successfully plug-in to at run-time. Rez might also be modified to 
work with Nasa World Wind’s tiling format, 

http://issues.worldwind.arc.nasa.gov/confluence/download/attachments/394/world+wind 

+tile+systemt. gif . 

The preceding can be done in order to more tightly couple with potential services that 
World Wind can provide the X3D-Earth Project. 

Currently, Google Maps utilizes Ajax calls to update a set of tiles within an outer 
div. An inner div also exists in this setup where tiles are added in an on-demand “just in 
time” fashion. The preceding is where the Ajax3D calls come into play. Rather than 
refreshing the page Google Maps utilizes Ajax calls to create the scrolling effect. An 
X3D-Earth application can act the same way updating the scene graph when more Rez 
tiles were demanded for a certain latitude-longitude pair rather than reloading the whole 
scene graph. In Google Maps, Mouse Listeners are utilized to detect when a user “drags” 
the map and can be easily mapped to event listeners (Touch Sensors) within the X3D 
specification. Justin Gehtland author of Pragmatic Ajax recently wrote a toy example of 
how Google Maps works but without the 2D georeferencing code that sits behind the 
application on the server-side 89 . Luckily, X3D-Earth does not have to worry as much 
about georeferenced tiles since Rez takes care of that and X3D already has a specification 


89 Justin Gehtland. Ajaxian Maps Example. 
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for Geospatial Nodes. Figure 127 is a screenshot of his “Ajaxian Maps” demo and a 
URL for the reader to explore and come to the conclusion that to pull off a similar feat, 
even if in 3D, is by no means impossible. 


|ftam I I hah Pin 


Spain - Population 



Figure 127. An example of Ajaxian Maps from [89]. 


Google Maps utilizes a URL to Tile architecture, employing servlets to look up 
the necessary tiles within the relevant viewing area and its respective zoom level. Within 
the architecture, each tile represents a known squared area. In the future, an X3D-Earth 
application might use similar techniques to take advantage of Web 2.0 technologies and 
services such as Ajax and REST and create an entirely server side but open standards set 
of X3D-Earth Web Services such as online GPS tracking. 

http://mt.google.com/mt?v=.l&x={x tile 

index}&amp;amp;amp;amp;amp;amp;{y tile index}=2&zoom={zoom level} 

Figure 128. Google Maps URL Schema for Servlet Calls from [88]. Note the X and Y 
dimension and the Zoom Level Requirements. 
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http://maps.google.com/maps? 

q=atlanta&z=13&sll=37,062500%2C-95.67 7 0 68&amp;amp;amp;amp;amp; amp; 
sspn=37,062500%2C80.511950&output=js 

Figure 129. Google Maps URL Schema for Servlet Calls when Search is requested from 
[88]. Note the q parameter requesting that Atlanta tiles be pulled up. 

Additionally, new nodes may need to be defined for X3D to create Google Earth 
type terrain overlays in X3D. X3D scene graph nodes might be updated via Ajax3D calls 
and be reminiscent of Google Maps overlays such as place marks and location balloons. 
The preceding will require much thought and the approval of a majority of the X3D-Earth 
Working Group, along with the Web3D consortium. Additionally, an alternative Proto 
node can also be looked at that resembles Google Earth’s Panel Control in KML. 

Modern day Ajax proxy frameworks such as ZK or ICEfaces are also more than capable 
of creating such a rich-UI that can feed an X3D scene space in the same tab control; 
providing server-side navigation, zoom, and drag-and drop functionalities. Furthermore, 
Ajax web-controls, specifically drag-and-drop controls, can provide additional GUI 
functionality above typical HTML or even JSF controls, making the X3D to KML 
mapping process much easier if a particular node is either missing or hard to implement 
and also introducing the ability to drag and drop from established 3D libraries such as 
Savage Studio into X3D space. A KML to X3D mapping using Proto Nodes or new 
X3D-Earth specific nodes are part of a new specification is likely critical to create a 
robust UI from within the X3D Browser itself and intelligent terrain overlays. 

In the long term a type of algorithmic modeling for 3D Buildings 90 in cities that 
are not landmark quality can also be explored. Google Earth and Microsoft Virtual Earth 
both use systems like the following to generate the majority of their low detail 3D 
Buildings. Figures 130, and 131 describe the use of computer vision to extrapolate 3D 
building information using stereoscopic techniques 91 . The significant benefit to doing so 
is auto generation of a lot of the less interesting buildings in a notional downtown 
skyline. 


90 Kim Taejung and Choi Soon Dal. (1995). A Technique for 3D Modeling of Buildings. 

91 Vosselman Suveg. (2002). Automatic 3D Building Reconstruction. 
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Figure 130. Diagram from A Technique for 3D Modeling of Buildings from [91]. Both 
researchers explored the extrapolation of 3D Buildings using stereoscopic techniques. 
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Figure 131. Automatic 3D Building Reconstruction Paper from [92]. This paper provides 
an example of leveraging computer vision algorithms to extract buildings from 

orthographic satellite data in. 
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C. OUTLOOK 

In general, DoD can integrate Ajax widgets into their web sites and web pages as 
to provide a more efficient usage of bandwidth across the GIG along with higher levels 
interactivity, richer controls, and increased modularity. At this point in the digital 
revolution it starts to become evident that mobile devices will play a more prominent role 
in the future. Such devices will only work better in a Web 2.0 environment with 
asynchronous calls to the server in a minimalist “just in time” fashion. Recently, the 
iPhone has shown the potential of Ajax-based Web Applications on Mobile Devices and 
the demand for such devices will continue to grow rapidly. DoD can benefit enormously 
from some of the current initiatives in Ajax frameworks such as the progress that the 
Dojo http://doiotoolkit.org/ project has made with offline-browsing which is applicable to 
forward deployed forces in minimal bandwidth situations. For a Web 2.0 enabled 
application, the specific MVC framework chosen is not as important as knowing why it 
was chosen over the others and being able to recognize when a given system must switch. 
The strengths and weaknesses of each individual framework are also important to be 
familiar with. With that being said, Spring, JSF and to a lesser-and-lesser degree, as of 
this publication date, Struts are widely recognized as the industry standards for MVC 
frameworks. 

In conclusion, while this thesis has explained many acronyms and buzzwords 
regarding Ajax and Web 2.0 specifically, the big takeaway for DoD Modeling and 
Simulation is that XML and that Ajax, or asynchronous client requests to the server-side 
has changed the way the web does business. It is also important to realize that today 
asynchronous requests from server to client are also possible with Comet (Reverse-Ajax) 
which provides intelligent streaming that has at least a chance of being scalable in 
practical application. Through, the promotion of open standards and XML on everything, 
the project manager can ensure that their current endeavor will be Web 2.0 enabled. In 
doing so, the enterprise can be ready to meet the demands of the next generation of 
warfare by leveraging the amazing amount of information and interoperability that the 
end-user gets as a result of asynchronous calls to the server-side from a rich client-side 
user interface. 
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Through the careful application of proxy framework-based Ajaxian widgets and 
the selection of appropriate Java EE application layer frameworks, DoD contractors and 
project managers will be able to provide value to the fleet with shorter development 
times, lower TCO, improved scalability, improved extensibility and a more robust and 
intuitive presentation layer. DoD web applications can now contain Ajaxian widgets that 
intrinsically have desired features that traditionally have cost many contractor 
development hours such as support for both client-side and server-side input validation 
and data-bound controls. In the realm of the 3D, Ajax3D offers developers a way to 
dynamically alter the 3D scene graph instead of having to reload after each change. The 
preceding is a huge paradigm shift that can allow the DoD to create 3D worlds on the 
web reminiscent of Google Earth but without the requirement of downloading software to 
what most likely will be an NMCI-client machine. Web applications deploy and scale 
much better than client-side applications, industry is starting to realize this and by 
employing industry best practices the DoD can get onboard as well to maximize the force 
multiplier that is the Internet and the new web paradigm that is Web 2.0 and Ajax. 
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APPENDIX A. DEFINITION OF RELEVANT TERMS 


Ajax (Asynchronous JavaScript and XML) 

http://en.wikipedia.org/wiki/AJAX 

Asynchronous JavaScript and XML, a term introduced by Jesse James Garret in 
2003 as a way of calling the server-side without a page refreshes. Ironically, Microsoft 
developed the XMLHttpRequest Object that makes this possible for a feature in 
Microsoft Outlook. However, Silicon Valley startups soon caught on to the idea and are 
now able to base entire frameworks on the technology to make new and exciting 
applications such as Google Maps. 

MVC (Model View Controller) 

http://en.wikipedia.org/wiki/Model-view-controller 

A way of abstracting out “separation of concerns,” which in English states that 
business logic must not reside in presentation code, (read HTML). In this paradigm, the 
model serves as the data that you clients need to access. The controller, in this case, is 
responsible for giving the clients views or “slices” of the model. Typically the controller 
in today’s industry is a full-on framework such as Struts, Spring or JSF (Java Server 
Faces). 

Polling 

http://en.wikipedia.org/wiki/Polling %28computer science%29 

Polling, or polled operation, in computer science, refers to actively sampling the 
status of an external device by a client program as a synchronous activity. Polling is most 
often used in terms of I/O (Input/Output) and is also referred to as polled I/O. With 
respect to Ajax, polling is querying the server-side for new information using JavaScript 
methods at regular intervals of time. Polling raises degradation issues due to problems in 
predicting what the appropriate interval of time actually is. If a developer does not 
choose the appropriate polling time and the rate of new server-side information is much 
greater than the rate at which new data gets polled then the architecture will start to lag 
considerably. 
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Google Gears 

http://gears.google.com 

Gears is software developed by Google which installs a small local web server 
and backend, (SQL-Lite) on the client in order to save “state,” and also to allow the client 
to navigate on a disconnected page via their local loop back interface on 192.168.1.1. 
Later on, at an opportune time when the client is once again connected to the web, Gears 
attempts to upload the old data asynchronously to the server-side, thus giving the client 
the illusion that they can work on a website even when offline. 

Server Push 

http://en.wikipedia.org/wiki/Server-push 

Server Push is an Ajaxian concept where the Server-Side determines when it is 
appropriate to call events on the client. For example, if an Ajaxian Stock Web 
Application suddenly gets notice of a major swing in the price of a certain ticker symbol 
an event Listener on the client can be triggered alerting any and all interested clients of 
the big change. 

Ecmascript 

http://en.wikipedia.org/wiki/ECMAScript 

JavaScript was originally developed in 1995. Ecmascript is the formal name of 
the JavaScript language specification approved by (ECMA) the European Computer 
Manufacturers Association. 

Aspect Oriented Programming (AOP) 

http://en.wikipedia.org/wiki/Aspect oriented programming 

AOP was developed by Gregor Kiczales at Xerox PARC in an attempt to 
minimize overlapping functionality in applications. AOP is another attempt to address 
separation of concerns, primarily crosscutting concerns, in software modules. One of the 
most-used examples of a crosscutting concern is the requirement to provide robust 
logging in the context of an application sever. In AOP traditional functions under the old 
Object Oriented (00) paradigm are called aspects or concerns. A common complaint 
concerning the 00 paradigm is that it does not adequately address behaviors that span 
over many modules. AOP is an attempt to redress the preceding grievances. In AOP 

aspects or concerns are also independent of any class, which is a big paradigm shift from 
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00. The idea behind AOP is to be able to inject frequently used aspects arbitrarily in the 
code rather than having to call modules with a standard method call. 

Aspects can be plugged-in to code at join-points, which can be thought of as 
traditional method calls. In AOP instructions or advice must be given to the framework 
at join-points to impose a thread of execution on the aspect. Join points are usually 
described with XML-descriptors, meta-data or regular expressions in AOP. 

Benefits of AOP include the ability to avoid using third-party APIs entirely so in 
practice a web application can communicate with an application server or 0/R (Object 
Relational) persistence layer, et al. with simple Plain Old Java Objects (POJOs). Modem 
day application severs typically have AOP concepts built in to their architectures. Sun’s 
latest Glassfish Web Container and the latest JBoss Application Server have elements of 
AOP in their architectures to be specific which is why at least a rudimentary 
understanding of AOP is of moderate importance for most project managers. 
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Figure 132. Diagram of notional Aspect Oriented Programming architecture from AOP. 
(2007). Wikipedia. Retrieved August 29, 2007 from 
http://en.wikipedia.org/wiki/Aspect oriented programming . Note the direction of the 
arrows showing the injection of functionality at different joint-points into the application. 

This paradigm is a big shift from OO in that AOP lets the application be passive and 
receive necessary aspects at runtime instead of calling them directly the old way, (APIs) 

and decreasing modularity. 


Inversion of Control (IoC) aka: Dependency Injection 

http://en.wikipedia.org/wiki/Inversion of control 

(Practical Application in the Spring Framework, JBoss Seam, JBoss Application 
Server and the Glassfish Application Server) 
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Figure 133. An illustration of IoC from Fowler, Martin. (2007). IoC. Retrieved September 
5, 2007 from http://martinfowler.com/articles/iniection.hml . The diagrram is showing 
the IoC framework or assembler creating a runtime concrete class dependency for a 
MovieLister based on an XML descriptor. In the XML descriptor, the persistence type 
(CSV, SQL, etc.) is tied to a specific concrete class, i.e., SQLMovieFinderlmpl.java or 
CSVMovieFInderhnpl.java making the MovieLister code much more reusable and 

modular. 


Inversion of control allows for a decoupling of dependencies from objects by 
passing them into the constructor as services in a just-in-time fashion, which allows for 
better modularity, unit-testing and reusability. For example, if a simple class was created 
to retrieve movie names (MovieLister) and it was based on a normal comma-separated 
values (CSV) flat-file but an associate wanted to use that same code to read XML, under 
a non IoC based code-base the code might need to be heavily re-factored. However, 
within an IoC framework, an interface to MovieLister can first be defined which was 
independent of its concrete class. At runtime, the IoC resolves MovieFinder calls the 
correct concrete class implementation and persistence type from XML descriptors on the 
server-side. In this paradigm a one to many relationship between interface and 
implementation can now exist because of the IoC. IoC can be thought of, as Applications 
running under an IoC-based container such as PicoContainer or Spring contain no direct 
references to their dependencies. Rather, the applications under such systems have their 
dependencies called for them by the IoC container and passed into the constructor or 
through a set function at runtime. Such a paradigm allows for packaged code to be 


155 



























created that is compile-time independent of its dependencies. Many Java EE application 
servers such as Spring are architected in this fashion to make the application server itself 
much testing-friendly and extensible. 

Singleton Pattern 

http://en.wikipedia.org/wiki/Singleton pattern 

Design Pattern that restricts the number of allowable instantiable objects to one. 

The pattern is typically called for when programming things like Factory interfaces, 

(Factory Pattern), print-spooling or file systems but needs to be handled with extreme 

caution since it can cause concurrency issues over the network. A Singleton Pattern is 

widely considered to be deceptively simple for that very reason. 

Anti-Pattern 

http://en.wikipedia.org/wiki/Anti-pattem 

Anti Patterns are also commonly known as pitfalls or Dark Patterns. Basically, an 
anti-pattern is just a common practice that at first appears like a good idea but, once 
carefully thought out (or put into production), becomes obviously detrimental. 
Interestingly enough, there are a ton of anti-patterns in several categories such as Project 
Management, General Design, Object Oriented (00) Design, Programming Design et, al. 
Some of the more famous anti-patterns are the “All You Have is A Hammer” anti-pattem 
in management, and the “Software Bloat” anti-pattem in Project Management, which is 
self-explanatory. 

Design Patterns: Gang of Four 

http://en.wikipedia.org/wiki/Gang of Four %28software%29 

This term refers to the four original authors, Erich Gamma, Richard Helm, Ralph 
Johnson, and John Vlissides who wrote the book Design Patterns in 1994. This specific 
book is an excellent reference for any project manager that has applications residing 
under the Java EE platform, as it was one of the first texts to describe such basic patterns 
as Fagadc, Adaptor and Bridge. The book gained much notoriety and is now considered 
classic. More than 500,000 copies have currently been sold in over 13 different 
languages worldwide. 
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Design Patterns is a must-read for anyone interested in patterns on the Java Platform. It 
is considered a landmark book in the world server-side development. Figure 134 is from 
Wikipedia, http://en.wikipedia.org/wiki/Gang of Four %28software%29 . 


Web 2.0 

http://en.wikipedia.org/wiki/Web 2 

Coined by O’Reilly Media in 2004 generally refers to a paradigm shift to a more 
robust web featuring new services such as Wikis, Folksonomies and also new client side 
abilities such as Asynchronous Client-Side Updates and Server Side Push. 

Reverse Ajax 

http://en.wikipedia.org/wiki/Reverse Ajax 

Reverse Ajax is different from Ajax, as Reverse Ajax is a suite of technologies for 
pushing data from a server to a client. These technologies are built into many modern day 
proxy frameworks such as Dojo Toolkit, DWR, and ZK. 

Comet Technology 

http://en.wikipedia.org/wiki/Comet %28programming%29 

A better solution might be for the server to send a message to the client when the 
event occurs, without the client having to ask for it. Such a client will not have to check 
with the server periodically; rather it can continue with other work and work on the data 
generated by the event when the server has pushed it. This is exactly what Comet sets out 
to achieve. Sun has bought in on the preceding idea by providing their own Comet 
support with their Glassfish Web Container. 
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Extensible 3D (X3D) 

http://en.wikipedia.org/wiki/X3D 

X3D is the ISO standard for real-time 3D computer graphics, the successor to 
Virtual Reality Modeling Language (VRML). X3D features extensions to VRML (e.g. 
Humanoid Animation, Nurbs, Geo VRML etc.), the ability to encode the scene using an 
XML syntax as well as the Open Inventor-like syntax of VRML97, and enhanced 
application programmer interfaces (APIs). 

Sketchup 

http://en.wikipedia.org/wiki/SketchUp 

3D Modeling Program by Google with the primary intention of supporting the 
new 3D Building technology that came with Google Earth 4. 

Keyhole Markup Language (KML) 

http://en.wikipedia.org/wiki/Kevhole Markup Language 

KML is an XML Google markup language for describing terrain overlays. KML 
is currently widely considered to be a de-facto industry standard and is awaiting Open 
Geospatial Consortium Approval. 

KMZ 

http://en.wikipedia.org/wiki/KMZ 

A KMZ file is a zipped file containing all of the terrain overlay infonnation in a 
file called doc.kml while the geometry and textures are stored in Collada format in their 
respective subfolders. 

Collada (Collaborative Design Activity) 

https://collada.org/public forum/welcome.php 

An XML based 3D Graphics Interchange format supported by The Khronos 
Group, http://www.khronos.org/ ,which now manages the OpenGL project. 
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APPENDIX B. CONTROLLER ARCHITECTURES 
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Figure 134. A high-level view of typical Struts architecture from [18]. Note that there is a 
clear separation of concerns between Presentation, Controller, and Business Logic within 

the architecture. 


Struts Lifecycle 
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Figure 135. A high-level view of a Struts Lifecycle from [18]. Note the common Struts 
practice of populating Action forms. Struts is also kn own as an Action-based 
architecture. Also note the native Struts support for both conversion and validation errors 

through XML descriptors. 
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Struts Action 


pub 1 11 class userActtetfi extends DLspdtchActien { 
private UserMonager mgr - null; 

piJbl ic V-oif! SC-tUSC-rHariugc-nCU &Ci"Mem(ijjcr UEC rMorvJgcrJ { 
rhi .r-fjr — usr-rMpFibg^r; 

public Act ton Forward deletetActionMapping mapping, Aetia^Foi’m Form, 

Http^ervletKGqc*est request, 
HttpServle-tstesponse -i l espofise3 

throws txception ( 

pyrtaActiariFerin userFerm — fDynaActionFonsJ form; 

User u-scr » Cp&cr> userform, gct( “ user '}; 

mgr , rc?navcUse«*frequest, flctHaraincte rC " u scr , i d M »; 

ActionFtessages messages - new Aeti on^ie ssogesQ; 

™?5-50gr5, raWC*Ctioni*jS5a{JCE .GlOtFAL-MtSSAIfjt: k 

new ActionMessageC “os-er , -deleted" , user. getFulI Ndtte<! >551 

saveMes sages (request. getSessi ati{ >, messages); 

return mapping. f t rtdF<>r*i! rdf *• use rs" 3: 

J 

’igure 136. An example of Struts Action Code on the server-side from [18]. Note that 
Struts Actions take a standard HttpServletRequest and HttpServletResponse object. The 
preceding underlines how the Struts framework effectively takes control of the standard 
HTML request/response paradigm and asserts its own control within the scope of the 

framework. 


struts-config.xml 

xForm-bean na«e»'userForm" type- "org. apache. struts . val idafeor . DynaVali datarForffl".> 
<f arm-property nerw-"use r “ type-“arg.app f use . model , User'W 
farm beans 


Figure 137. The main XML configuration file for Struts telling it what beans to listen from 
the client-side forms from [18]. Note that on the Java platform most Model View 
Controller Frameworks and Application Servers utilize XML-based descriptors for their 
configuration due to code-maintainability and the ability to hot-deploy in test- 

environments. 
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Struts: JSP View 

<>(■*1: fiWi* Ktloftx'Vyitr" focwm'Ufl r , f If stunt" ertiiit*1H;x'Vttlli J i"i 1 ■)'> 

^LnpuL lyp£x"!l LCdCI!* noiti'M Luc" val u«v'sawe'*/> 

<t tnl :*i LddGn jjyfiiJGrty- “Slier . Id V> 

«.table cl-ni*x“i1'f fcflU"'j 

<tr> 

at 4 l f ir-'user. ftp, i i rstlH'^iv Lol>« L>-r/th?- 
■ctdhufitail j test prnptrty»"uiGr. f L rsfcKarc'* lty r ! cEil- " jl ,-2 r. fL ritNare VWgiI* 

*/*.?>■ 

■Ar> 

■ t t-■'. jL- ,for-' uaer. l,QitPtone'‘ , ><dT«t; Biisafle ke^“uicr, I m tH&fw'V*! 
dibnlitixt prnpertjf-“uier. ] a ithaK' alylcr^'i^er . 1 di tHnne“/> 

c-:.pnr'i (lin**x“^ Lfl ill rpor"«h 1 ■!: e rrur^ prapp-r'i/x^L 5*1" ■ taf 

■c/t±> 

<fchMtobel for* "iiaer .bL rthday^tfnc :nr asag* k«/»"u icr. birthday"/> :</lnbv: 
vtd> 

cf;ut v^Px'iliitP-Fiil :er^i"r-c'wP iiWujaiyii Miy«”deit*.fcrwt - p>«/c:Sit> 

^::nput typ'j-"tej.t 1J slze*'ll‘ J *inftt-' , Nacr.bL''thtfay J (d—'user. birthday “ 

v ill. i •• 'll iri:l|. II'J. I'I li: IT. >vj|i. Mt <!- - l.i I l t I'lkiiyJ 

p-atterr- "S{dntePuttErnJ-“ ■'<■". (IfdotcPattcrn)] 

s/td> 

■etr* 

"igure 138. A diagram showing Struts connection stubs within the Presentation Layer 
from [18]. Note the Struts Tags and the call to the Application Layer, i.e., the User Bean, 

in this case. 



Figure 139. Spring MVC Architecture from the Spring Framework Home Page, 
http://www.springframework.org . Accessed: August 2007. Note the Aspect Oriented 

Programming support. 
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Spring Controller 

ptfilic doss U&erC-ontroller iiplenents Controller { 

private Final Leg log - L^actiiry.getlegLIJierCantroSUr.cloeE)j 
private UserHmifer wr = null; 

public void sitlfeerHana^ertUserHcn^er uarUsnager) { 
this.agr ■■ uEorHanager; 

} 

public HMteUndVitw tendleRequestCKttpSe~MletReqLest request, 

HttpServlelResponse response) 

throws Exception { 

if (lagdsDeixigEnc&lfrdO) { 

Iflfl.detugC’enterUg ' handieReauest' ietibod. 

} 

return ner< H>delArdl'lei*t 'userLisf, 'jsers', rtgr.gtetUsersO); 

i 

} 


Figure 140. Java code showing a typical Spring Controller from [18]. Note how much 
cleaner the implementation of the Spring Controller is than the Struts method of 

ActionForms. 
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Spring: Configuration 


<ban idp n iierContro11 e r' t \ o 5 S- n orQ, oppose,wb, UserCwtro-l ler* > 
property nc«re- n us.erMflnc]|fer*' reVus*rtiii»flger ,, fr 
</bean> 

id= Vie^esol'/fir" 

c E Q4S*"dirg . spr i ng f rcmc-wrk . w? b. M rvlet. vie*. In terndResaur :e,' iertdesfik ye r m > 
property naw-MewClftss" values“org.sjringfrontwiorit.*sb. serwl et.vieiv.JstLYit#7> 
property <iai*Vprefix" value*"/ Y> 
property (tone- 1 suffix" valuer" t jsp7> 

</beans 

<&ecm td='firlMapptng" 

c l as&="arg. spr ing F r*e»rk . rteb, se rvlet. haitd Iter. SirpleUrlHird It rMoppingY 
tprcperty (name* toppings "> 

/ users, hul*usi! i'Cm tro-lle r 

</value> 

property* 

</bear> 

Figure 141. A typical Spring Configuration File from [18]. Note the bean to class, or 
entity to business-logic mapping taking place in the code. 
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coniform (;C'WMn 4 'lalH!="g|^ , ’ , rpeth 0 d= P p 3 it ,r > 
tfan: errors pdtlw"*" fssClfli^ernor’A 
<forn:hid£en path*" id" /> 

<iabU dfl5s-"MoU"> 
df> 

<thxlabel for/firstfcu'V 

d&mwyt key-' , user. Ft rstNome '/>: </label> </to> 

<td> 

<fom:input patha tlrsUtflie" id»*firstft«eV> 
tfom:errors (wt^ n FiritNflM p cssClas&-"fieldError’/> 
</td> 

</tr> 

dlixlobel fDrw"ldstNM 1 ' c lass-Tequi red’> 

1 <fat:«K5flgG Jfey-"u&Er.lostl!kiieV>:^lDbftiK / th? 
dd> 

<ftni: input ptith»"ldit!!;iie n id» p fiPStli(iJte7:» 
<fan:N , rors |Mth»1astNfliie" c&5Clu5s»' , Field£rrar7> 

<ftr> 


Figure 142. A notional Spring JSP Presentation Layer from [18]. Note that the fonn 
paradigm is still used however, it is less archaic in that now the Java entity-beans map 
directly to form input fields. As was seen in the configuration file the beans are 
subsequently mapped to Java classes on the server-side. 
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Spring Web Flow 

V A web framework that allows you to define page 
flows In youi' application 

0- In XML (or programmatically in Java), you specify 
simple or complex navigation rules 

O' Navigation rules enforced based on the String value 
that a method returns {similar to JSF) 

O' Can call middle-tier methods declaralively - no 
controllers needocJl 


Figure 143. A summary of Spring Web Flow from [18]. 


Spring Web Flow 


ewnbFta’N l,d= +, y■s^5l , Flow Etarl setupFcrwr 

<aet i'Dn- state L d-“se tu pF nrn"> 

■ide t n un tc-an-“ui4. , -rF ormAct i®n‘V> 

■itriin^iJtirjmi r•J^l-‘Wuccl^■^s' , lrr>= - dl sp-lfiy. nomfF(snii - /> 

^/□Eticn itato 

»:uk.cw-state ld'*iltiplay .nunEFtn" v lew-"f l cm/ntMno"’ 

■:troni it ion un- “ su-ba L t “ ta- L spt ay. add rc s i F urnf :■ 

•met ion bean- " inerfa rmAt tLon" methods “b LrdflrKlUa li dutc "/>■ 
c/transitLon> 

■:traniitloni un-" t(inC.cl “ Lnlih"/* 

states 

■rv lew- state id- ‘ d L sp lay.. utld re !• & I’o '■w" vieiv- "-FLuwi/nddrtii"> 

^transition un-"prfivLOus" to-'diiploy. niim!ro™”> 

taction betjn-"u&crformAttLDn" method-"!^ndftridValidute "/> 
■Vtrdni it lbn> 

■-tram It Lon an- ” subirtt " to- ”d L spl ay . ather F*rm“ , > 

•<d£.t lisa btdr-" ifSeiT armAct L dpi" method- "to l ridAridUdl i date "/> 

•-J tram it Lon> 

^transition &n-"£antel “ lsh"/> 

■^view-state:- 

Figure 144. A notional Spring Web Flow XML descriptor showing how the Model View 
Controller framework can establish logical links between pages to match the appropriate 
work flow for enterprise business processes. Figure 144 is from [18]. 
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Figure 145. A modern day (JSF) Java Server Faces architecture from [18]. Note that the 
Presentation, Application, and Business Logic layers are still separated. Also note, that 
validation and most importantly event-handling have been added. 
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this. .Id - Id; 
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public void ietUief(Uier iistr> { 
thii.uw — uhf; 

1 


public void actUacrMat'dacr£.UitrMonoQor 
kdis.ingir — uacrMaiiflgc-r; 

J 

uierMananiiO 1 

public £>iPina iilllO t 

If C 1 J f - nul 1 > { 

// dllUHlna rill 

Mtlfkdi'Cngr. ytitOiiSiFCldS} , 

1 


return ^^uuLvik"; 

J 



Figure 146. A basic JSF entity bean from [18]. Note the JSF implementation of beans is 
clean and comprised of mainly setters as might be expected. 
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^managed-beam 

managed - bean - name;’ user Form u'mnge d ■■ bean ■ rm& 

managed - bean -c L a s s >org. a pp f use. «b, User Form </ma naged -bean’ c lass> 

managed - bean - s c o 2 c> reque st <Jm nnge d - bean - sc&pe> 

managed-property 

<p rope rty-a m >i ik/p r ope rty- nam ie> 

<va l ue>#{parain. l d} </value> 

</ianaged’property> 
managed - prope r ty> 

^property namouserManagerf/prcperLy raie> 

<va 1 ue>#{ u s e rfeinager} </val ue> 

</ma!iaged-property> 

</*anaged-bean> 


Figure 147. A typical JSF Configuration File from [18]. There is nothing particularly 
ground- breaking here just more beans mapped to classes and to a particular scope, i.e., 
session, request or response. It is of note that the new Seam framework from JBoss lets 
developers extend scope to transactions, which adds scopes such as contextual, 
transaction, and business process to the list of available scopes. 
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JSF JSP View 


<f:^icn> 

<f:lodBiirfle var=>ssttj«s“ bas€na«e= H itss£ijes"/> 

di:ffrri id= ri ii^fF^rfi"> 

■iti: UiiiutHid un va ( ut=”# luserFom. 11 ser. I d} "> 

<f:cMivertNunwr/> 

</h r lnputltLdden> 

■itirpiiieUr.i; toluim^T StyUCtol£="dltfltr CCl(iflCl(HSti=^loter> 

ditoirtpbt Label YflluSi7{«iM£s[ 1 us* r.ftrstHoit 1 ]} > 

di:lfyutTttt valine= _ f{us.^ r'Ffirm. us^r.firitHait} " id='firitH<ane-" > 
dirntsscjje f*r="firstJla>e" styleClasi="errfl ^essfoge' f> 

<ti: du tpL t Labe I fcr=‘ las tH iw H val ue=" i {«i iogsfis [‘u^er.l ti&tMane * ]) "/> 

di: Input fat val«=" ^{uterForm.us«r,lastHawe} " ic^lMtNime’ reqLLrsds H triK"/> 

di:iesitse far=^fatltow" £tyltClai£= H 4jwHfr&^7^ 

<fi: outpiitLdbe I for=“ bi rtltday“ val us =" i {■« sagas [ 1 u ser b irthday 1 ]} 7> 
d: Irtpiittaltndar manttiy^arRowiflas s^tirttanthJteoder* 
weklfatla ss= H iree kHeedsr" i d="b: r liidfty H 

cn rrejitQaytel '. tl ass=‘ djjt erittayCe oal l«= ' f{ut&rfor™. use r. bi rthddy} " 
rende rAs.Papup= K trur addltesouitess H f abe H /> 

_ duwemni* fflr=*MrtMg¥" styltClnis="arftirHe-isfli;t7> _ ■ m 

Figure 148. An example of a notional (JSP) Java Server Page containing JSF at the 

Presentation Layer from [18]. 
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JSF JSP View 
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Figure 149. Real world application of JSF standard web controls from [18]. Note how 
rich the client-controls are compared to traditional FITML controls. In JSF, each control 
has event listeners and properties that can be changed with backing beans such as a 

session bean or an entity bean. 


New in JSF 1.2 


& Unified EL - better support for J STL 
&■ R>e us on ease of use 
O Java Studio Creator 2,0 

Many Ajax Components and Examples 

& Open Source; ADF Faces, MyFaces/Tomahawk, 
Facelets 


Figure 150. A listing of new features in JSF 1.2. Glassfish, JBoss, Web Sphere and most 
other Application Servers now offer full support for JSF 1.2. Figure 150 is from [18]. 
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Evaluation Criteria 

List Screens: How easy is it to code pageable, 
sortable lists? 

9 Bookmarkability: Can users bookmark pages and 
return to them easily? 

9 Validation: How easy is it to use and does it support 
client-side (JavaScript) validation? 

9 Testability: How easy is it to test Controllers out of 
container? 


Figure 151. A listing of MVC architecture evaluation criteria from [18]. This is part one 

of three. 


Evaluation Criteria, cont. 

9 Post and Redirect: How does the framework handle 
the duplicate post problem? 

Spring Integration: Does the framework support 
using Spring in the middle tier; how easily? 

9 Internationalization: } low is 118n supported and 

how easy is it to get messages in Controllers? 

9 Page Decoration: What sort of page decoration/ 
composition mechanisms does the framework 
support? 


Figure 152. A listing of MVC architecture evaluation criteria part from [18]. This is part 

two of three. 
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Evaluation Criteria, cont. 

£ Tools: Is there good tool (particularly IDE) support 
for the framework? 

£ Marketability of Skills: If you learn the framework, 
will it help you get a job? 

9 Job Count: What is the demand for framework skills 
on dice.com? 


Figure 153. A listing of potential MVC architecture evaluation criteria from [18]. This is 

part three of three. 


List Screens 

How easy is ii to integrate a sortable/pageabJe list of 
data ? 

& Struts, Spring MVC and Web Work can all use 
Tag Libraries like the Display Tag 

Q Tapestry has a contrib:Table component 

® JSF has a dataTable with no sorting - have to 
write your own logic if you want it 


Tgure 154. A comparison of List Screen, i.e., paginated data feasibility comparison 
between MVC frameworks. Figure 154 is from [18]. 
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Bookmarking and URLs 

9 Using container-managed authentication (or other 
filter-based security systems) allow users to 
bookmark pages. They can click the bookmark, 
login and go directly to the page. 

£ WebWork has namespaces - makes it easy 

£ Struts and Spring allow full URL control 

£ Tapestry still has somewhat ugly URLs 

£ JSF does a POST for everything - URLs not even 
considered 

Figure 155. A comparison of the ease of ensuring operational Book marking, by correctly 
handling dynamic state, in various MVC architectures. Figure 155 is from [18]. 


Validation 


® Validation should be easy u> configure, be robust on the 
client side and either provide good out of the box messages 
or allow you to easily customize them. 

Q Struts and Spring MVC use Commons Validator - a 
mature solution 

V Web Work uses OGN l for powerful expressions - client 
side support is awesome 

O Tapestry has very robust validation - good messages 
without need to customize 

© JSC - ugly default messages, but easiest to configure 


Figure 156. A comparison of validation schemes in various MVC architectures from [18 
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Testability 

9 Struts - can use StrutsTestCase 

9 Spring and Web Work allow easy testing with mocks (o.g. 
EasyMock, jMock, Spring Mocks) 

9 Tapestry appears difficult to test because page classes are 
abstract, Creator class simplifies 

9 |SE page classes can be easily tested and actually look a lot 
like Web Work actions 


"igure 157. A comparison of Testability in various MVC architectures. Figure 157 is 

from [18]. 


Post and Redirect 

9 The duplicate-post problem, what is it? 

9 Easiest way to solve: redirect after POST 

9 Is there support for allowing success messages to live through 
a redirect? 

9 Struts and Spring are the only framework that allows 
success messages to live through a redirect 

9 WebWork requires a custom solution 

0 Tapestry requires you to throw an Exception to redirect 

9 JSF requires a custom solution, n &n messages difficult to 
gel in page beans 


Figure 158. A comparison of how Posts and Redirects are handled in various MVC 

architectures. Figure 158 is from [18]. 
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Spring Integration 

Spring 

9 All frameworks have integration with Spring 

9 Struts: ContextLoaderPlugin and Support classes 

9 WebWork: SpringObjectFactory (built-in) 

9 Tapestry: Easily plug Spring into Hivemind 

9 fSF; DelegatingVariableResolver or JSF-Spring 
I ibrary 


Figure 159. A listing of the various frameworks that can plug-in to Spring due to its 
inherent flexibility. Figure 159 is from [18]. 


Internationalization 


9 JSTL/s <fmt:message> lag makes it easy 

9 No standard for getting i 1 On messages in r:ontroller 
classes 

9 Siruts, Spring and jSF use a single Resource Bundle 
per locale 

9 WebWork and Tapestry advocate separate files for 
each page/action 

9 JSF requires resource bundle to be declared on each 
page 

9 Tapesiry's <span key="key.name"> is awesome _ 

Figure 160. A comparison of the ability of various frameworks to support web site 
internationalization, or the ability of the site to be shown in various configurations for 
different languages. Figure 160 is from [18]. 
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Page Decoration 

G iites Experience: used since it first came out 
Q SileMesh is much easier to setup and use 
G Tiles can be used in Struts, Spring and ]SF 
^ Requires configuration for each page 
9 Site Mesh can be used with all frameworks 
d Requires very little maintenance after setup 
9 Use both for powerful decoration/composition 


: igurc 161. A comparison on how easily various MVC frameworks can template their 
respective presentation layers. Figure 161 is from [18]. 


Tools 


^ Struts has a lot of IDE support and even has 
frameworks built on top of it (i.e. Beehive's 
Page Flow) 

^ Spring has Spring IDE - only does XML validation, 
not a Ul/web tool 

V WebWork has EclipseVVork 

^ Tapestry has Spindle - great for coders 

^ JSE has many, and they're getting better and better 


Figure 162. A comparison of the amount of development tools available in various MVC 

architectures. Figure 162 is from [18]. 
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Tools Available 



Figure 163. A chart listing the various tools available in modern MVC architectures. Note 
that JSF and Struts are currently most prevalent frameworks. Figure 163 is from [18]. 


Marketability of Skills 

^ Struts is still in high-demand and widely-used 

^ Spring is getting more press, but mostly due to the 
framework's other features 

9 Web Work is gaining ground, but very scarce on job 
boards 

^ Tapestry is even more scarce - needs more 
marketing 

£ JSF is quickly becoming popular 


Figure 164. Slide showing developer job-market concerns that might face influence their 
decision when choosing to learn a new Model View Controller framework. Figure 164 is 

from [18]. 
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Dice Job Count 


2,000 



October 15. 2004 June 9, 2005 February 13, 2006 


1 Web Work 

■ Struts 

I Spring MVC 
Tapestry 

■ |SF 


Figure 165. A chart showing Dice (Employment Web-site) Job Count Demand by MVC 

Architecture. Figure 165 is from [18]. 


What do others think? 


Figure 166. 
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AppFuse Usage 


Web Work 
Struts 

Spring MVC 
JSF 

Tapestry 


lMtpe//raibledesign&-COOl/pagerrdtentry spring_mvi: llie most popular 


A chart showing various opinions on MVC throughout industry. Figure 166 is 

from [18]. 
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APPENDIX C. NON-AJAXIAN JAVASCRIPT DATEBOX 


dateBox.js 2002-01-09 


Author(s): Serge Ryabcuck, z555.com. Copyright 2002 

z555.com grants you a royalty free license to use or modify this 

software provided that 

this copyright notice appears on all copies. 

This software is provided "AS IS," without a warranty of any kind. 

*/ 


/* ToDo 


- Masks like dd/mm/yyyy, mm/dd/yyyy, etc. 

- Redraw of the object 

after change of object style properties. 

- Rewrite some object 

methods for conforming with initial idea 

and remote direct HTML objects calls for properties duplicates 

*/ 


window.dblE = document 

.all ? true : false; 

// IE 4 + 


window.dbDOM = (document.getElementByid && ! document.all) ? true : 

false; // NS6, Mozilla, 

other DOM2 compartible browsers 

function dateBox(name, 

month, day, year) { 

this.name 

= name; 

this.day 

= day; 

this.month 

= month; 

this.year 

= year; 

this.id; 


this.version 

= "2.0.1 [Date Box; 20020109] "; 

this.type 

= "dateBox"; 

this.startYear 

= 1998; 

this.endYear 

= 2008; 

this.height 

II 

I— 1 

Oh 

this.shortMonthWidth 

= 47; 

this.longMonthWidth 

= 87; 

this.dayWidth 

= 38; 

this.yearWidth 

= 54; 

this.fontFamily 

= 'Arial, Verdana, Helvetica, Espy, Sans- 

Serif'; 


this.fontSize 

= '8pt'; 

this.dateBoxStyle 

= 'long'; 

this.shortMonth = [ 

'Jan', 'Feb', 'Mar', 


'Apr', 'May', 'Jun' , 


'Jul', 'Aug', 'Sep', 

]; 

'Oct', 'Nov', 'Dec' 

this.longMonth = [ 

'January', 'February', 'March', 


'April', 'May', 'June', 
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'July', 'August', 'September', 
'Octovber', 'Novvember', 'December' 

] ; 

// Other Properties; 
this.HTMLcontainer; 
this.objForm; 
this.objMonth; 
this.objDay; 
this.objYear; 

// Methods 


this.getName 


getName; 

this.setDay 

= 

setDay; 

this.getDay 

= 

getDay; 

this.setMonth 

= 

setMonth; 

this.getMonth 

= 

getMonth; 

this.setYear 

= 

setYear; 

this.getYear 

= 

getYear; 

this.getID 

= 

getID; 

this.setStartYear 

= 

setStartYear; 

this.getStartYear 

= 

getStartYear; 

this.setEndYear 

= 

setEndYear; 

this.getEndYear 

= 

getEndYear; 

this.getDateBoxStyle 

= 

getDateBoxStyle; 

this.setHeight 

= 

setHeight; 

this.getHeight 

= 

getHeight; 

this.setShortMonth 

= 

setShortMonth; 

this.getShortMonth 

= 

getShortMonth; 

this.setLongMonth 

= 

setLongMonth; 

this.getLongMonth 

= 

getLongMonth; 

this.getMonthWidth 

= 

getMonthWidth; 

this.setDayWidth 

= 

setDayWidth; 

this.getDayWidth 

= 

getDayWidth; 

this.setYearWidth 

= 

setYearWidth; 

this.getYearWidth 

= 

getYearWidth; 

this.getMonthName 

= 

getMonthName; 

this.setFontFamily 

= 

setFontFamily; 

this.getFontFamily 

= 

getFontFamily; 

this.setFontSize 

= 

setFontSize; 

this.getFontSize 

= 

getFontSize; 

this.setObjPointers 

= 

setObjPointers; 

this.makeDateHTML 

= 

makeDateHTML; 
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this.printHTML = printHTML; 

this.monthDays = monthDays; 

this.limitList = limitList 

this.getObjForm = getObjForm; 

this.getObjDay = getObjDay; 

this.getObjMonth = getObjMonth; 

this.getObjYear = getObjYear; 

this.getObjSelectedDate = getObjSelectedDate; 
this.setRawDate = setRawDate; 

this.setObjDate = setObjDate; 

//Events 

this.onSelectDate = onSelectDate; 

var curDate = new Date(); 

if (Imonth) { this.month = curDate.getMonth()+1 }; 
if (!day) { this.day = curDate.getDate() }; 
if (!year) { 

if (window.dbDOM) { 

this.year = curDate.getYear()+1900; 

} else { 

this.year = curDate.getYear(); 



if (!window.dateBoxes) window.dateBoxes = new Array(); 
this.id=window.dateBoxes.length; 

window.dateBoxes[window.dateBoxes.length] = this; 


///////////////////////////////////////////////////////////// 
// dateBox.getName() 
function getName() { 

return this.name; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setDay() 
function setDay(day) { 
this.day=day; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getDay() 
function getDay () { 

return this.day; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setMonth() 
function setMonth(month) { 
this.month = month; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getMonth() 
function getMonth() { 
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return this.month; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setYear () 
function setYear(year) { 

this.year=year; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getYear () 
function getYear() { 

return this.year; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getID () 
function getID () { 

return this.id; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setStartYear () 
function setStartYear(year) { 

this.startYear = year; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getStartYear () 
function getStartYear() { 

return this.startYear; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setEndYear() 
function setEndYear(year) { 

this.endYear = year; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getEndYear() 
function getEndYear() { 

return this.endYear; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getDateBoxStyle () 
function getDateBoxStyle() { 

return this.dateBoxStyle; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setShortMonth() 
function setShortMonth(monthArray) { 
this.shortMonth=monthArray; 

} 

///////////////////////////////////////////////////////////// 

// dateBox.getShortMonth() 

function getShortMonth(monthlndex) { 
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return this.shortMonth[monthlndex-l] ; 


} 

///////////////////////////////////////////////////////////// 
// dateBox.setLongMonth() 
function setLongMonth(monthArray) { 
this.longMonth=monthArray; 

} 

///////////////////////////////////////////////////////////// 

// dateBox.getLongMonth() 

function getLongMonth(monthlndex) { 

return this.longMonth[monthlndex-l] ; 

} 

///////////////////////////////////////////////////////////// 

// dateBox.getMonthName() 

function getMonthName(monthlndex) { 

if (this.getDateBoxStyle() == 'short') { 
return this.getShortMonth(monthlndex) ; 

} else { 

return this.getLongMonth(monthlndex); 

} 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setHeight() 
function setHeight(height) { 

this.height = height; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getHeight() 
function getHeight() { 

return this.height; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setShortMonthWidth() 
function setShortMonthWidth(width) { 
this.shortMonthWidth = width; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setLongMonthWidth() 
function setLongMonthWidth(width) { 
this.longMonthWidth = width; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getMonthWidth() 
function getMonthWidth() { 

if (this.getDateBoxStyle() == 'short') { 
return this.shortMonthWidth; 

} else { 

return this.longMonthWidth; 

} 

} 

///////////////////////////////////////////////////////////// 

// dateBox.setDayWidth() 
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function setDayWidth(width) { 
this.dayWidth = width; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getDayWidth() 
function getDayWidth() { 

return this.dayWidth; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setYearWidth() 
function setYearWidth(width) { 
this.yearWidth = width; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getYearWidth() 
function getYearWidth() { 

return this.yearWidth; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setFontFamily () 
function setFontFamily(family) { 

this.fontFamily=family; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getFontFamily() 
function getFontFamily() { 

return this.fontFamily; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setFontSize () 
function setFontSize(size) { 

this.fontSize=size; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getFontSize () 
function getFontSize() { 

return this.fontSize; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getObjForm() 
function getObjForm() { 

return this.objForm; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getObjDay() 
function getObjDay() { 

return this.objDay; 

} 

///////////////////////////////////////////////////////////// 
// dateBox.getObjMonth() 
function getObjMonth() { 

return this.objMonth; 

} 
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///////////////////////////////////////////////////////////// 

// dateBox.getObjYear () 
function getObjYear() { 
return this.objYear; 

} 

///////////////////////////////////////////////////////////// 

// dateBox.makeDateHTML() 
function makeDateHTML() { 

var dateStr = 

// Build Month 

dateStr += '<select name="' + this.getName() + 'Month' + 

'" style="font-family : ' + this.getFontFamily() + 

'; HEIGHT: ' + this.getHeight() + 'px; WIDTH:' + 

this.getMonthWidth() + 'px; font-size: ' + 

this.getFontSize() + 

';" onChange="window.dateBoxes[' + this.getIDO + 

'] .onSelectDate()">' ; 

for (i=l; i<=12;i++) { 

if (this.getMonth() == i) { 

dateStr += '<option selected value=' + i + ’>' + 
this.getMonthName(i) ; 

} else { 

dateStr += '<option value=' + i + ’>' + this.getMonthName(i); 

} 

} 

dateStr += "</select>"; 

// Build Day 

dateStr += '<select name="' + this.getName() + 'Day' + 

'" style="font-family : ' + this.getFontFamily() + 

'; HEIGHT: ' + this.getHeight () + 'px; WIDTH: ' + 

this.getDayWidth() + 'px; font-size: ' + 

this.getFontSize() + 

';" onChange="window. dateBoxes [ ' + this.getIDO + 

'] .onSelectDate ()">'; 

for (i=l; i<=31; i++) { 

if (this.getDay () == i) { 

dateStr += '<option selected>'+i; 

} else { 

dateStr += '<option>'+i; 

} 

} 

dateStr += "</select>"; 

// Build Year 

dateStr += '<select name="' + this.getName() + 'Year' + 

'" style="font-family : ' + this.getFontFamily() + '; 

HEIGHT: ' + 

this.getHeight() + 'px; WIDTH: ' + this.getYearWidth() + 

'px; font-size: ' + this.getFontSize () + 

';" onChange="window.dateBoxes[' + this.getIDO + 

' ] .onSelectDate()">'; 

for (i=this.getStartYear (); i<=this.getEndYear(); i++) { 

if (this.getYear () == i) { 

dateStr += '<option selected>' + i; 
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} else { 

dateStr += '<option>' + i; 

} 

} 

dateStr += "</select>"; 
this.HTMLcontainer=dateStr; 

} 

///////////////////////////////////////////////////////////// 

// dateBox.printHTML() 
function printHTML() { 

document.write(this.HTMLcontainer) ; 

this.setObjPointers(document.forms[document.forms.length-1]) ; 
this.limitList(this.monthDays(this.getMonth() , this.getYear())) ; 

} 

///////////////////////////////////////////////////////////// 

// dateBox.setObjPointers () 
function setObjPointers(form) { 
this.objForm = form; 

this.objDay = eval("form."+this.getName()+"Day"); 
this.objMonth = eval("form."+this.getName()+"Month"); 
this.objYear = eval("form."+this.getName()+"Year"); 

} 

// How many days in the month? 

// dateBox.monthDays() 
function monthDays(month,year) { 

var day = new Array (31,28,31,30,31,30,31,31,30,31,30,31) ; 
month—; 

if ((year % 4 == 0) && (month==l)) { 
if (year % 100 == 0) { 

if (year % 400 == 0) { 

return 29; 

} else { 

return 28; 

} 

} else { 

return 29; 

} 

} else { 

return day[month]; 

} 

} 

// Event processor 
// dateBox.onSelectDate () 
function onSelectDate() { 

if (window.dblE || window.dbDOM) { 
var objDay=this.getObjDay(); 
var objYear=this.getObjYear() ; 
var objMonth=this.getObjMonth() ; 

yearVal=objYear.options[objYear.selectedlndex].text; 
monthVal=objMonth.options[objMonth.selectedlndex].value; 
this.limitList(this.monthDays(monthVal, yearVal)) ; 

this.setDay(objDay.selectedlndex+l) ; 

this.setMonth(objMonth.selectedlndex+l) ; 

this.setYear(objYear.selectedlndex+this.startYear) ; 

} 


} 
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//Rebuilds dropdown list of day options according to the month 
///////////////////////////////////////////////////////////// 
// dateBox.limitList () 
function limitList(length) { 
list=this.getObjDay() ; 
if (length<(list.selectedlndex+l)) { 

list.selectedlndex=length-l; 

} 

if (window.dblE || window.dbDOM) { 
if (list.options.length<length) { 

for (var i=list.options.length+1; i<=length; i++) { 

var oOption = document.createElement('OPTION') ; 
if (window.dblE) { 

list. options.add(oOption) ; 
oOption.innerText = i; 
oOption.Value = i; 

} else if (window.dbDOM) { 
oOption.text = ' 'ti; 
oOption.Value = i; 
list.add(oOption,null); 

} 

} 

} else if (list.options.length>length) { 

for (var i=list.options.length; i>=length; i—) { 

list.remove(i); 

} 



} 

// Convert form fields to Date object 

///////////////////////////////////////////////////////////// 

// dateBox.getObjSelectedDate() 
function getObjSelectedDate() { 

if (window.dblE || window.dbDOM) { 
var objDay=this.getObjDay() ; 
var objYear=this.getObjYear() ; 
var objMonth=this.getObjMonth() ; 

var day=objDay.options[objDay.selectedlndex].text; 

var month=objMonth.options[objMonth.selectedlndex].value-1; 

var year=objYear.options[objYear.selectedlndex].text; 

var dateObj = new Date(year, month, day); 
return dateObj; 

} 

} 

// Set specified Date 

///////////////////////////////////////////////////////////// 

// dateBox.setRawDate() 
function setRawDate(month,day,year) { 

if (window.dblE || window.dbDOM) { 
var objDay=this.getObjDay() ; 
var objYear=this.getObjYear() ; 
var objMonth=this.getObjMonth() ; 

this.limitList(this.monthDays(month, year)) ; 
objDay.selectedlndex=day-l; 
objMonth.selected!ndex=month-l; 




objYear.selectedlndex=year-this.startYear; 

} 

} 

///////////////////////////////////////////////////////////// 
// dateBox.setObjDate () 
function setObjDate(date){ 

if (window.dblE || window.dbDOM) { 
var month = date.getMonth()+1; 
var day = date.getDate(); 
if (window.dbDOM) { 

var year = date.getYear()+1900; 

} else { 

var year = date.getYear (); 

} 

this.setRawDate(month,day,year); 

} 

} 
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